4 ms·

NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. You also want to ca

by Maro 15y ago

NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff).

batista 15y ago
NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. Per gmail account, you'd still dump all the mails into one gigantic emails table, either an SQL or a NoSQL one. As for the totality of the gmail accounts, well, you'd use sharding, which is the same whether you use NoSQL or SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff). But a SQL DB can also use the same transparent API for the persistent stuff with their standard Query API. It wouldn't even need to parse the SQL statement, just hash it and compare it. And you could also use a layer that makes it transparent, such as an ORM.
- Maro 15y ago
  So you'd have one 'emails' table per Inbox, right? So for 1 million users, you'd have 1 million tables, and no SQL database can handle that.
mattmanser 15y ago
Huh, why wouldn't you want those tables? You seem to be confusing the need to scale with how you would design the system. Somewhere I worked before we used to import 100,000s of a companies email into the project system to display them against the system. They were all in an Emails table which just stored the body, I think there was an email header table and an email contacts table which was relationally linked directly to the Person table. Worked fantastically, used to run an IMAP server off those tables for outlook integration.
- Maro 15y ago
  I wasn't talking about "email" as a use-case, I was talking about "Gmail". Obviously you can serve 1000s of email users using an SQL and IMAP database.

by Maro 15y ago

batista 15y ago

NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. Per gmail account, you'd still dump all the mails into one gigantic emails table, either an SQL or a NoSQL one. As for the totality of the gmail accounts, well, you'd use sharding, which is the same whether you use NoSQL or SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff). But a SQL DB can also use the same transparent API for the persistent stuff with their standard Query API. It wouldn't even need to parse the SQL statement, just hash it and compare it. And you could also use a layer that makes it transparent, such as an ORM.

Maro 15y ago
So you'd have one 'emails' table per Inbox, right? So for 1 million users, you'd have 1 million tables, and no SQL database can handle that.

mattmanser 15y ago

Huh, why wouldn't you want those tables? You seem to be confusing the need to scale with how you would design the system. Somewhere I worked before we used to import 100,000s of a companies email into the project system to display them against the system. They were all in an Emails table which just stored the body, I think there was an email header table and an email contacts table which was relationally linked directly to the Person table. Worked fantastically, used to run an IMAP server off those tables for outlook integration.

Maro 15y ago
I wasn't talking about "email" as a use-case, I was talking about "Gmail". Obviously you can serve 1000s of email users using an SQL and IMAP database.