Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What could a modern database do that PostgreSQL and MySQL can't

news.ycombinator.com

Post reply on HN
Print view View original

321–326 of 326 posts

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#321

Post by yencabulator »

josephg wrote: post #201
mirekrusin wrote: post #33

Earlier quoted context omitted.

It always rubs me the wrong way - all those paxos/raft approaches (which are great, but...) simply elect the leader to pick writes. In that sense there is no distribution of computation at all. It's still single target that has to cruch through updates. Replication is just for reads. Are we going to have something better anytime soon? Like real distribution, when you add more servers writes distribute as well?

> Like real distribution, when you add more servers writes distribute as well? There's a really interesting suggestion in The Mythical Man Month. He suggests that instead of hiring more programmers to work in parallel, maybe we should scale teams by keeping one person writing all the code but have a whole team supporting them. I don't know how well that works for programming, but with databases I think its a great id…

> I could imagine making a single CPU core's job to be simply ordering all incoming writes relative to each other

Calvin is an interesting alternate design that puts "reach global consensus on transaction order" as its first priority, and derives pretty much everything else from that. Don't even need to bottleneck through a single CPU.

http://cs-www.cs.yale.edu/homes/dna/papers/calvin-sigmod12.p...

Like VoltDB, the one huge trade-off is that there's no `BEGIN ... COMMIT` interaction where the client gets to do arbitrary things in the middle. Which would be fine, if programming business logic in the database was saner than with Postgres.

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#322

Post by yencabulator »

I would love to see support for compute near data ("stored procedures") that is compatible with today's practices: real programming languages, version control, testing, etc.

Calvin (http://cs-www.cs.yale.edu/homes/dna/papers/calvin-sigmod12.p...) and VoltDB are examples of different architectures that trade off the ability to do SQL-style interactive transactions (`BEGIN`+run code client side+`COMMIT`), forcing everything through predefined procedures. Combining that with better stored procedures is interesting.

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#323

Post by yencabulator »

One thing Firestore's JS client library does that is very interesting is that mutations by the in-browser client show up in persistent queries, even before they sync with the server, even offline. You can tell which changes are safe on the server and which not by metadata.

This greatly improves latency and simplifies code. Trying to manually merge the mutations into all of your queries would be very awkward.

Also, the whole concept of browser clients interacting directly with the database server is darn interesting. Combine that with better support for stored procedures etc for actually enforcing business logic (somewhat made possible by Firestore security rules, but very awkward).

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#324

Post by hodgesrm »

josephg wrote: post #313
hodgesrm wrote: post #304

Earlier quoted context omitted.

What you suggest would work if you just want to order writes. However, it won't support an ACID transaction model, which a lot of applications expect, or even simpler models where you can read values before you write. For instance: consider an application that looks at the current value of a counter and adds 1 if the counter is less than 100. You can execute this on the primary (resource bottleneck because you need t…

> However, it won't support an ACID transaction model I think you could add ACID support, while the process doing ordering still not caring about the data. You do something like this: - Split the keyset into N buckets. Each bucket has an incrementing version number. (The first change is 1, then 2, then 3, and so on). The whole system has a vector clock with a known size (eg [3, 5, 1, 12, etc] with one version per buc…

I'm really sorry didn't see your comment earlier. I like your solution but am a little stuck on the limitations.

1.) It requires applications to specify the entire transaction in advance. ACID transactions allow you to begin a transaction, poke around, change something, and commit. You can derive the transaction by running it on a replica, then submitting to the primary, in which case this becomes an implementation of optimistic locking including transaction retries.

2.) As you pointed out the trick is to keep the array small. However, this only works if you have few conflicts. Jim Grey, Pat Helland, and friends pointed this out in 1996. [1] That in turn seems to imply a very large number of buckets for any non-trivial system, which seems like a contradiction to the conditions for high performance. In the limit you would have an ID for every key in the DBMS.

3.) Finally, what about failures? You'll still need a distributed log and leader election in case your fast machine dies. This implies coordination, once again slowing things down to the speed of establishing consensus on the network to commit log records.

Incidentally Galera uses a similar algorithm to what you propose. [2] There are definitely applications where this works.

[1] https://dsf.berkeley.edu/cs286/papers/dangers-sigmod1996.pdf

[2] https://galeracluster.com/library/documentation/certificatio...

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#325

Post by topspin »

zozbot234 wrote: post #144
topspin wrote: post #120

Earlier quoted context omitted.

"Consider using Postgres views!" The minute you create a view modifying the underlying table usually gets blocked, in many cases even for changes that have zero relevance to the view. You have to drop the view(s) to get the ALTER TABLE to go through. Absolute nightmare. Oracle, for example, does a far better job of handing this type of evolution and dependency management.

> You have to drop the view(s) to get the ALTER TABLE to go through. So? With Postgres you can use transactions in your DDL. So it's possible to seamlessly drop the view, alter the underlying table and recreate it, all in one step once the transaction is commited.

"it's possible to seamlessly drop the view, alter the underlying table and recreate it"

And if that were the only problem it wouldn't be too bad, except that other databases don't inflict this task or limit the degree of the problem far better. Unfortunately the problem isn't limited to views. Materialized views, for instance, have to be dropped and recreated along with their indexes. That can involve a large IO operation; one that risks failure.

Pretty soon an otherwise innocuous ALTER TABLE that conceptually has zero impact on dependencies becomes a major undertaking.

Re: Ask HN: What could a modern database do that PostgreSQL and MySQL can't

#326

Post by jfbaro »

1) Native Bi temporal capabilities without hurting (too much) performance.

2) Distributed DB, like Spanner and CRDB.

3) Real time analysis of performance and then adapt the DB config accordingly, without requiring HUMAM intervention.

4) Multiple (joint?) storage types per table (Memory, Columnar or Rows, for example);

5) Native support for Copy On Write replicas (useful for ephemeral environments, Stage and development)

6) Serverless capabilities

Post reply on HN