5 ms·

"Spanner / TiDB / Cockroach" Eh. Use old boring dbs: mysql, etc. Systems with decades of fixes, stackoverflow posts, work arounds, migration tools, etc. Other

"Spanner / TiDB / Cockroach" Eh. Use old boring dbs: mysql, etc. Systems with decades of fixes, stackoverflow posts, work arounds, migration tools, etc. Otherwise - you will learn Spanner doesn't support deletes of 100k rows in 2022 and it is discontinued in 2023 (lol made up prediction). New db tech is pretty terrible (excluding vitess db - which is now industry standard). I wouldn't treat it like a JS framework.

yehosef 4y ago
you should check out singlestore.
KronisLV 4y ago
TiDB also claims MySQL compatibility at the protocol level, but the amount of unsupported features is slightly demotivating: https://docs.pingcap.com/tidb/stable/mysql-compatibility#unsupported-features https://docs.pingcap.com/tidb/stable/mysql-compatibility#uns... Here's some of what's not supported: Stored procedures and functions Triggers Events User-defined functions FOREIGN KEY constraints #18209 FULLTEXT syntax and indexes #1793 SPATIAL (also known as GIS/GEOMETRY) functions, data types and indexes #6347 Character sets other than ascii, latin1, binary, utf8, utf8mb4, and gbk. SYS schema Optimizer trace ... Not being able to use FOREIGN KEY constraints makes me distrust the viability of something like that, because in my experience DB schemas and how they're utilized without foreign key end up being dumpsterfires. Then again, at a certain scale you kind of have to look into alternative ways of how to look at working with your data, so there's that. That said, the idea of giving people something that's compatible (for the most part) with the drivers and syntax that they already utilize is an excellent one!
billythemaniam 4y ago
Spanner can delete >100k rows if partitioned DML is used. TiDB is already what Vitess is trying to be. I think you would be surprised the number of companies who touted Vitess publicly that either went to TiDB or back to vanilla MySQL.
tmountain 4y ago
Case in point, Drizzle. It had backing from Google, RedHat, Sun, HP, etc. The fork had over 10k commits, and it was supposed to unseat MySQL as the SaaS cloud DB. Then, the project was just canceled because, “nobody had time to work on it”. Picking boring tech for crucial areas of a business is almost always the best plan. https://en.m.wikipedia.org/wiki/Drizzle_(database_server) https://en.m.wikipedia.org/wiki/Drizzle_(database_server)
- hodgesrm 4y ago
  Drizzle failed because it didn't have a use case that made it clearly better than MySQL. It's hard to displace an incumbent DBMS, because they take a long to time to mature internally as well as develop a productive ecosystem.
  - tmountain 4y ago
    Sure it did, it provided a default charset that wasn’t latin_swedish_ci. Clearly I am joking, but the selling point was supposed to be that it provided a lean, mean, modernized MySQL replacement. I think the problem was that replacements under the hood don’t necessarily translate to an improved UX.
    - hodgesrm 4y ago
      Exactly.

yehosef 4y ago

you should check out singlestore.

KronisLV 4y ago

TiDB also claims MySQL compatibility at the protocol level, but the amount of unsupported features is slightly demotivating: https://docs.pingcap.com/tidb/stable/mysql-compatibility#unsupported-features https://docs.pingcap.com/tidb/stable/mysql-compatibility#uns... Here's some of what's not supported: Stored procedures and functions Triggers Events User-defined functions FOREIGN KEY constraints #18209 FULLTEXT syntax and indexes #1793 SPATIAL (also known as GIS/GEOMETRY) functions, data types and indexes #6347 Character sets other than ascii, latin1, binary, utf8, utf8mb4, and gbk. SYS schema Optimizer trace ... Not being able to use FOREIGN KEY constraints makes me distrust the viability of something like that, because in my experience DB schemas and how they're utilized without foreign key end up being dumpsterfires. Then again, at a certain scale you kind of have to look into alternative ways of how to look at working with your data, so there's that. That said, the idea of giving people something that's compatible (for the most part) with the drivers and syntax that they already utilize is an excellent one!

billythemaniam 4y ago

Spanner can delete >100k rows if partitioned DML is used. TiDB is already what Vitess is trying to be. I think you would be surprised the number of companies who touted Vitess publicly that either went to TiDB or back to vanilla MySQL.

tmountain 4y ago

Case in point, Drizzle. It had backing from Google, RedHat, Sun, HP, etc. The fork had over 10k commits, and it was supposed to unseat MySQL as the SaaS cloud DB. Then, the project was just canceled because, “nobody had time to work on it”. Picking boring tech for crucial areas of a business is almost always the best plan. https://en.m.wikipedia.org/wiki/Drizzle_(database_server) https://en.m.wikipedia.org/wiki/Drizzle_(database_server)

hodgesrm 4y ago
Drizzle failed because it didn't have a use case that made it clearly better than MySQL. It's hard to displace an incumbent DBMS, because they take a long to time to mature internally as well as develop a productive ecosystem.
- tmountain 4y ago
  Sure it did, it provided a default charset that wasn’t latin_swedish_ci. Clearly I am joking, but the selling point was supposed to be that it provided a lean, mean, modernized MySQL replacement. I think the problem was that replacements under the hood don’t necessarily translate to an improved UX.
  - hodgesrm 4y ago
    Exactly.