4 ms·

That's bs. With wal-e it took a few hours tops to set up a basic master-slave system from scratch if you didn't know what you're doing. I'd have to imagine it's

by gfodor 12y ago

That's bs. With wal-e it took a few hours tops to set up a basic master-slave system from scratch if you didn't know what you're doing. I'd have to imagine it's easier now. With proper automation adding a replica should be as simple as booting a machine and running a script or two. I don't care either way I just use RDS and don't worry about it. (You can add replicas in one click with RDS.)

threeseed 12y ago
I can't tell from the documentation whether wal-e supports non-cloud based synchronisation (https://github.com/wal-e/wal-e https://github.com/wal-e/wal-e). There's no example listed there. And if you think that is as simple as MongoDB's replica sets then frankly you are crazy.
- takeda 12y ago
  Wal-E is a backup solution, and has something that Mongo doesn't it is capable of backing up every transaction and restoring the database state at any point in time. Because of its nature it can be used for replication. Wal-E was written for use in cloud which has its own challenges, but if you want to run in your data center the closest thing is Swift in OpenStack. As for Mongo, my company is currently using it, and I wouldn't say it's any easier especially when you try to use it in public cloud, when you no longer have guarantees that the instance you set up won't be terminated and recreated in different AZ. There are plenty of challenges. I'm currently working on convincing other teams to drop using Mongo and instead make queries directly to Postgres which is our authoritative source of data. The idea was to simplify our infrastructure, and I was not expecting much difference in performance but oh boy. In all of my POCs that I did so far PG is beating Mongo that makes you feel sorry for it. Both in performance (you need to understand what you're doing and use right types, indices and queries) and data size (after moving, the data is much smaller so it no longer requires being distributed, and also the instances can be much smaller).
  - tracker1 12y ago
    Mongo is perfectly capable of point in time restores... in fact Mongo corp has a SaaS that does this... I know of several who have done the same on their own. There's been plenty of work in side-channel events with Mongo's log shipping system. Perhaps you can point to a relatively simple walkthrough to setup PostgreSQL with plv8 for replication (with an easy promotion of a slave to master), that doesn't take a commercial support license... Everything I've seen seems incredibly convoluted and more difficult than say MS-SQL, MongoDB, RethinkDB, ElasticSearch or several other databases at data replication and spinning up new nodes, or handling a primary failure. Also, most of my work with Mongo has performed very well, if your data is a good fit, which I will admit it isn't all a good fit. Honestly, I'd rather use pgsql with plv8 over mongo, or elasticsearch, or ms/azure-sql... The support costs and my time are important to me, and better spent working on architecture or development. If I can make an operations level decision that works well enough, or is easier to scale then the development time is almost a wash.

by gfodor 12y ago

threeseed 12y ago

I can't tell from the documentation whether wal-e supports non-cloud based synchronisation (https://github.com/wal-e/wal-e https://github.com/wal-e/wal-e). There's no example listed there. And if you think that is as simple as MongoDB's replica sets then frankly you are crazy.

takeda 12y ago
Wal-E is a backup solution, and has something that Mongo doesn't it is capable of backing up every transaction and restoring the database state at any point in time. Because of its nature it can be used for replication. Wal-E was written for use in cloud which has its own challenges, but if you want to run in your data center the closest thing is Swift in OpenStack. As for Mongo, my company is currently using it, and I wouldn't say it's any easier especially when you try to use it in public cloud, when you no longer have guarantees that the instance you set up won't be terminated and recreated in different AZ. There are plenty of challenges. I'm currently working on convincing other teams to drop using Mongo and instead make queries directly to Postgres which is our authoritative source of data. The idea was to simplify our infrastructure, and I was not expecting much difference in performance but oh boy. In all of my POCs that I did so far PG is beating Mongo that makes you feel sorry for it. Both in performance (you need to understand what you're doing and use right types, indices and queries) and data size (after moving, the data is much smaller so it no longer requires being distributed, and also the instances can be much smaller).
- tracker1 12y ago
  Mongo is perfectly capable of point in time restores... in fact Mongo corp has a SaaS that does this... I know of several who have done the same on their own. There's been plenty of work in side-channel events with Mongo's log shipping system. Perhaps you can point to a relatively simple walkthrough to setup PostgreSQL with plv8 for replication (with an easy promotion of a slave to master), that doesn't take a commercial support license... Everything I've seen seems incredibly convoluted and more difficult than say MS-SQL, MongoDB, RethinkDB, ElasticSearch or several other databases at data replication and spinning up new nodes, or handling a primary failure. Also, most of my work with Mongo has performed very well, if your data is a good fit, which I will admit it isn't all a good fit. Honestly, I'd rather use pgsql with plv8 over mongo, or elasticsearch, or ms/azure-sql... The support costs and my time are important to me, and better spent working on architecture or development. If I can make an operations level decision that works well enough, or is easier to scale then the development time is almost a wash.