3 ms·

I use Mongo & its been working great. Our data is not relational (imagine you were tasked with building "Powerpoint" on the web). Compared to mysql I like that

I use Mongo & its been working great. Our data is not relational (imagine you were tasked with building "Powerpoint" on the web). Compared to mysql I like that it has automatic failover out of the box. I can also just add new replica set members without having to stop the master or bring a slave offline to rsync it over. With something like mysql I have to learn about & choose between row based replication or statement based replication. I have to choose between binary logging or global transaction ID logging. With Mongo I just call rs.init() and rs.add() and it "just works". Perhaps I'm just not hitting the level of traffic where the problems begin to surface, or maybe postgres would be better... but its been great so far. No complaints. The only issue was de-normalized data getting out of sync due to bad coding in our app, which i do not blame Mongo for (and was simple to fix).

lotyrin 9y ago
Of course I don't know your product, but when I imagine Powerpoint-as-a service, do users not relate to decks which relate to slides which relate to the content on those slides? Content itself of course would probably be a pretty flexible tree structure. An app full of queries like "Get me all the content of slide Y of deck XXXX... or don't if the current user YYY doesn't have access to that" would make me itching for indices and foreign constraints across what definitely feel like relations to me. And for the non-relational content blobs, Postgres's partial indices + indexes on expressions would make some fairly intricate reports like "since we launched the image embedding feature, per week, what percent of created or modified slides contain images", "who are the top 10 users in terms of edits to content tree items, and what subscription level do they have" pretty neat and fast. If you're in early stages such that you don't want to hire or acquire DBA skills, you're probably well served by offloading replication/backup/verification (which are all very possible with RDBMS) to e.g. AWS's RDS product. HA is important, is covered by replication+failover. Periodic backups are important, are covered by a export+rotate schedule. Point-in-time restores are important, are covered by storing replication logs. All are covered by a managed RDBMS, so you need to know what they are and how they work, but not implement or manage them. Most of the NoSQL deployments I've seen just rely on the out-of-the-box replication, and get HA but that's it. The engineers I've seen that don't want to understand the simple high-level ramifications-to-developers of RDBMS replication don't want to understand ramifications-to-developers about their NoSQL replication either, and they take a risk of encountering those ramifications needlessly unforeseen. As the data grows, yeah, maybe you'll eventually hit technical or economical limits that mean you'll want to manage your own RDBMS with an application-tuned replication and sharding scheme, so you'll want to hire or train at that point -- but there's huge huge room to play within the economic and technical characteristics of modern managed cloud RDBMS-as-a-service for any app that has a hint of a business model, given that we measure the cost of such services in cents per billion unit-hours.
- joshribakoff 9y ago
  > Get me all the content of slide Y of deck XXXX But that's not a query I ever need. I load the user's document, which contains an array of slide (embedded documents). There is no relation between documents & slides, slides are part of the document. But take it one step further & imagine you have a variety of widgets that can be placed on slides, with no common schema between them. Your choice is model out 100s of tables, use EAV, or go noSQL. We did the latter. > would make me itching for indices and foreign constraints Mongo has indexes. Regarding foreign keys it does not have that, but usually you can just embed the document in all the places you need it (de-normalization). Which can be a problem, so if you don't want de-normalization you should definitely use a SQL DB, not mongo. > Postgres's partial indices + indexes on expressions would make some fairly intricate reports like "since we launched the image embedding feature, per week, what percent of created or modified slides contain images" Mongo has aggregation which has fortunately been able to perform all the reporting I've needed so far. I'm sure postgres is nice as well.

lotyrin 9y ago

Of course I don't know your product, but when I imagine Powerpoint-as-a service, do users not relate to decks which relate to slides which relate to the content on those slides? Content itself of course would probably be a pretty flexible tree structure. An app full of queries like "Get me all the content of slide Y of deck XXXX... or don't if the current user YYY doesn't have access to that" would make me itching for indices and foreign constraints across what definitely feel like relations to me. And for the non-relational content blobs, Postgres's partial indices + indexes on expressions would make some fairly intricate reports like "since we launched the image embedding feature, per week, what percent of created or modified slides contain images", "who are the top 10 users in terms of edits to content tree items, and what subscription level do they have" pretty neat and fast. If you're in early stages such that you don't want to hire or acquire DBA skills, you're probably well served by offloading replication/backup/verification (which are all very possible with RDBMS) to e.g. AWS's RDS product. HA is important, is covered by replication+failover. Periodic backups are important, are covered by a export+rotate schedule. Point-in-time restores are important, are covered by storing replication logs. All are covered by a managed RDBMS, so you need to know what they are and how they work, but not implement or manage them. Most of the NoSQL deployments I've seen just rely on the out-of-the-box replication, and get HA but that's it. The engineers I've seen that don't want to understand the simple high-level ramifications-to-developers of RDBMS replication don't want to understand ramifications-to-developers about their NoSQL replication either, and they take a risk of encountering those ramifications needlessly unforeseen. As the data grows, yeah, maybe you'll eventually hit technical or economical limits that mean you'll want to manage your own RDBMS with an application-tuned replication and sharding scheme, so you'll want to hire or train at that point -- but there's huge huge room to play within the economic and technical characteristics of modern managed cloud RDBMS-as-a-service for any app that has a hint of a business model, given that we measure the cost of such services in cents per billion unit-hours.

joshribakoff 9y ago
> Get me all the content of slide Y of deck XXXX But that's not a query I ever need. I load the user's document, which contains an array of slide (embedded documents). There is no relation between documents & slides, slides are part of the document. But take it one step further & imagine you have a variety of widgets that can be placed on slides, with no common schema between them. Your choice is model out 100s of tables, use EAV, or go noSQL. We did the latter. > would make me itching for indices and foreign constraints Mongo has indexes. Regarding foreign keys it does not have that, but usually you can just embed the document in all the places you need it (de-normalization). Which can be a problem, so if you don't want de-normalization you should definitely use a SQL DB, not mongo. > Postgres's partial indices + indexes on expressions would make some fairly intricate reports like "since we launched the image embedding feature, per week, what percent of created or modified slides contain images" Mongo has aggregation which has fortunately been able to perform all the reporting I've needed so far. I'm sure postgres is nice as well.