Thank you Alex for your feedback, I greatly value these thoughts and always enjoy learning new details in this space.
On Wed, Oct 13, 2021 at 10:07 AM Alex Miller <millerde...@gmail.com> wrote: > These two pieces together seem to imply that your claim is that Read > Committed may read whatever the most recently committed data during > the execution of the statement and does not require MVCC. Though I > agree that the standard[1] is very unclear as to what a "read" means > when defining a non-repeatable read: > I responded to Blake's similar comment on this topic. Out of respect for his request to move the discussion to a newly created thread, I will not elaborate here rather just reference my reply to Blake. The following observation seems more relevant for Accord itself and the discussion on trade-offs, so I'll allow myself to continue within this thread: > > On Tue, Oct 12, 2021 at 3:55 PM Henrik Ingo <henrik.i...@datastax.com> > wrote: > > Approach: The conversational part of the transaction is a sequence of > > regular Cassandra reads and writes. Mutations are however executed as > > read-queries toward the database nodes. Database state isn't modified > > during the conversational phase, rather the primary keys of the > > to-be-mutated rows are stored for later use. Accord is essentially the > > commit phase of the transaction. All primary keys to be updated are the > > write set of the Accord transaction. There's no need to re-execute the > > reads, so the read set is empty. > > As I've pondered this over time, I personally specifically fault > read-your-uncommitted-writes as the reason why NewSQL databases are > essentially a design monoculture. Every database persists uncommitted > writes in the database itself during execution. Doing so encourages > those writes to be re-used for concurrency control (ie. write > intents), and then that places you in the exact client-driven 3PC > protocol which Cockroach, TiDB, and YugaByte all implement. Even if > you find some radically different database for SQL, like leanXcale, it > _still_ persists uncommitted writes into the database. > > This is an interesting point of view... I simply assumed this approach is inherited by the fact that single server RDBMS implementations are built this way, and NewSQL solutions reuse well known designs for the database engine. > And every time I've thought through this, I tend to agree. It's too > exceedingly easy to write a SQL query which will exceed any local > limit imposed by memory, and it's too easy to write a query which runs > fine in production for a while, until it hits a memory limit and > begins to immediately fail. There's a tremendous implementation > difference between `DELETE FROM Table` and `TRUNCATE Table`, and it's > relatively hard to explain that to naive users. > > Memory constraints aside, merging a local write cache into remote data > for execution seems like it'd be quite a task. Any desire for > efficient distributed query execution would push for a design where > query fragments can be pushed down to the nodes holding the data. Reading this I realize... Aren't you actually pointing out a limitation in any "single shot" transactional algorithm? Including Accord itself, without any interactive part? What you are saying is that an Accord transaction is limited by the need for both the client, and coordinator, to be able to keep the entire transaction in memory and process it? Where Cassandra is coming from, I'm not particularly alarmed by this limitation as I would expect operations on a Cassandra database to be fast and small, but it's an important limitation to call out for sure. Indeed, those who have been worried Accord will not be able to serve well all possible future use cases may have found their first meaningful concrete example to add to the list? henrik -- Henrik Ingo +358 40 569 7354 <358405697354> [image: Visit us online.] <https://www.datastax.com/> [image: Visit us on Twitter.] <https://twitter.com/DataStaxEng> [image: Visit us on YouTube.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_channel_UCqA6zOSMpQ55vvguq4Y0jAg&d=DwMFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=IFj3MdIKYLLXIUhYdUGB0cTzTlxyCb7_VUmICBaYilU&m=bmIfaie9O3fWJAu6lESvWj3HajV4VFwgwgVuKmxKZmE&s=16sY48_kvIb7sRQORknZrr3V8iLTfemFKbMVNZhdwgw&e=> [image: Visit my LinkedIn profile.] <https://www.linkedin.com/in/heingo/>
