@Konstantin 1. It's ok in my cases. 2. Not required in my cases. 3. Just require users to use different servers for now I think. Sometimes(always?) users can be greedy with feature requests. 4. I want magically consistency + failover (I can instruct the client to retry all masters).
Good-cluster is the only thing that is stopping postgresql from killing many nosqls in my opinion. Citusdb is single-master(can't even update many rows on the same shard), Postgres-XL has no highavailibility (and having 3 servers per node + global dtm), GreenPlum is olap(and old version of postgres), app-side sucks. With sharding, the holy-grail is to have automatic-global-range-partitioning (hypertable,hbase,cockroachdb,bigtable etc) on the primary-key or a special column. The con of this, is that indexes of a row reside in another region, which may mean another server, which you need cross-server-transaction to update a row. In this case, I think you can save the indexes on the same server as the row and be fine. To have good speed you can implement: 1-shard-only-queries (no cross-nodes transaction), async-disk changes (so the changes are done only in the memory of all replicated servers and not in commit-log (used by couchbase)). Multi-shard transactions aren't needed as much in my opinion. 5. The fewer places/files there are to configure any system the better it is IMHO. Cheers and good luck! On Fri, Apr 1, 2016 at 8:15 PM, Moreno Andreo <moreno.and...@evolu-s.it> wrote: > Il 01/04/2016 17:22, Joshua D. Drake ha scritto: > >> On 04/01/2016 04:50 AM, Konstantin Knizhnik wrote: >> >> There are also some minor technical issues which lead us to making few >>> changes in pglogical code but we tried to do our best to keep original >>> versions unchanged, so we can switch to public version in future. >>> >> >> It seems the better solution for all of this would be for BDR and this >> project to come together as a community project to get multimaster for >> PostgreSQL. Otherwise we are going to end up with the same situation we had >> before Pg had master-slave replication. >> >> JD >> >> I'd like to post my use case, hoping it could be of any interest. > We are giving a cloud service, based on our professional application, > hosting databases on our server and replicating them to every site the > users register with. > Every user have (for now) a unique database to keep in sync. > Users write on their local database and data is replicated with the server > via a background process running while user is connected. > Actually we have to improve what our replicator is doing: it's only > replicating the single user's database. The improvement should that we can > put it on the "server" (in some cases there are groups of users sharing a > dedicated server) and, given a configuration of what and how to replicate, > it should replicate more than one DB a time. > Actually, it's a stand-alone program, but what we'd like would be > something more integrated in PostgreSQL, so where PostgreSQL can run > (everywhere!), so can it. > We were beginning to "translate" (and then improve) this program in c#, > when I bumped into articles pointing to BDR, and I started taking a look. > But it seems that is good to replicahe whole servers, and still hasn't the > granularity we need. > > My 2 cent... > > Cheers, > Moreno. > > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
