Hacker News Reader

Comment by Patrol8394 | Hacker News Reader

These days I’d probable take a closer look at spanner. It is a consistent and scalable db. It makes life much easier for developers.

Like Cassandra, dynamodb requires the data model to be designed very carefully to be able to get the max out of them.

More often than not, that simply adds more complexity; people often underestimate how much a sharded mysql/Postgres can scale.

My default choice for the longest time: Postgres for the data I care about, ES as secondary index and S3 as blob storage.

View on HN

True. Spanner and the likes of Spanner, CockroachDB, YugaByte all are strongly consistent and scalable dbs. The greatest advantage IMO is the ability to just use SQL without having to worry about carefully designing a data model. What bothers me however is that these data stores are not truly relational data stores. They spin a relational layer on top of a scalable key-value data store.

Is it necessary to use a strongly consistent transactional data store if your needs don't demand transactions, by transactions I mean 2PC. IMO you are still better off with DynamoDB/Cosmos/MongoDB for eventual consistency use cases. The reason being, you have to resort to a data model if you don't need the relational layer in YugaByte at least, not sure about Spanner. So why bother with Yugabyte if am resorting to a data model. Might as well stick with DynamoDB.

I think VoltDb (and SciDB) are worth checking out also. I'm seeing some very impressive ACID compliant TPS with elixir connected to voltdb. I don't like having to pay to get distributed features however (open source community edition is feature gimped compared to payed.)

What part of SQL requires not having to design a data model? What exactly do you mean by that?

And technically all relational databases are relational layers on top of a key/value subsystem. Splitting that apart and scaling the storage is how most of the NewSQL databases scale , from CRDB to Yugabyte to Neon.

What I mean is that the data model in the NoSQL world is tightly coupled with the query pattern. So you define the query pattern and then tailor the data model to that query pattern. In the relational world, you typically choose the index based on your query pattern. Not tailor the data model to your query pattern. You follow normalization principles.

Of course, every data store needs a data model. No debate there :).

Not sure what you mean by relational databases are relational layers on top of key-value stores. InnoDB has a 16KB page data as it's fundamental data structure.

https://dev.mysql.com/doc/internals/en/innodb-page-structure...

You seem to think MongoDB is eventually consistent. MongoDB is designed as strongly consistent database. You can choose to query a secondary and that will be eventually consistent but that is not the default behaviour.

I must have clarified, what I mean by strong consistency is that you have transactional support (2 phase commit). MongoDb is atomic, meaning every single document is strongly consistent. However, I stand corrected. They have introduced transactions as of 4.2.

I believe multi document transactions offer only causal consistency?

> What bothers me however is that these data stores are not truly relational data stores

Suggests there may be an impossibility theory lurking somewhere.

Global strict serializability is coming to Cassandra very soon [1]

[1] https://cwiki.apache.org/confluence/download/attachments/188...

Reply on news.ycombinator.com