Why SQL is beating NoSQL, and what this means for the future of data

Re:Why SQL is beating NoSQL, and what this means for the fut... by jjirsa on Tuesday September 26, 2017 @10:34PM (#15344457)

Primary key conflicts are still a thing. Especially problematic where you're either not using auto_incrementing PKs, and/or you try to switch writes from one master to the other and app has to be aware of the switch.

[ Parent | on HN ]

Re:Why SQL is beating NoSQL, and what this means for the fut... by stephenr on Tuesday September 26, 2017 @10:46PM (#15344521)

Not using auto incrementing keys is surely a rarity with MySQL projects.

Even before galera was a thing regular MySQL replication could use auto_increment_(increment|offset) to make each server generate unique id's.

[ Parent | on HN ]

Re:Why SQL is beating NoSQL, and what this means for the fut... by jjirsa on Wednesday September 27, 2017 @12:26PM (#15349407)

There exists a LOT of data models that don’t use auto incrementinf primary keys. Rarity or not, it’s a real use case and a real problem for master/master replication

Also, even if you do use auto increment with offsets for each server, you’ll have to know how many servers you’ll eventually have, or waste offsets and eventually risk outrunning your data types

[ Parent | on HN ]

Re:Why SQL is beating NoSQL, and what this means for the fut... by stephenr on Wednesday September 27, 2017 @12:33PM (#15349481)

Non auto keys will already need some way to ensure uniqueness that will involve the application expecting conflicts.

For those that do use auto inc, galera will manage the offset/increment value based on cluster size automatically.

[ Parent | on HN ]