3 ms·
The big issue here is the idea of moving logic to the data, rather than data to the logic. One of these things is much bigger than the other. If you have a mult
by jhugg 10y ago
The big issue here is the idea of moving logic to the data, rather than data to the logic. One of these things is much bigger than the other. If you have a multi-statement transaction with intersitial logic, client-side logic is going to get absolutely smoked by a stored procedure.
There are downsides; suddenly logic in your app is split between client side and server side, which is annoying.
At VoltDB, we do our best to make the situation better than it is in more traditional systems.
- Stored procedures are Java, and can be unit-tested and debugged live.
- Stored procedures can be transactionally added, removed and upgraded in a cluster-wide operation that happens at a single-logical point in time.
- Stored procedure code (and schema) is archived with all snapshots, allowing for portability.
- You can run stored procedures on your laptop development machine, then push the same bits to a pre-production cluster, then push the same bits to production.
- Stored proceudres can share code and even use inheritance, reducing putting the same logic in many places.
One way to look at it is the set of prepared statements and procedures on your VoltDB cluster is sort of a state/processing-API. It works really well when you’re processing streams of events and you have one procedure per event type.
- mdellabitta 10y agoYou say JDBC is slow, but what if you're using PreparedStatements and PreparedStatement caching? Isn't that similar?
- jhugg 10y agoJDBC doesn’t have to be slow. VoltDB actually caches ad-hoc SQL plans so even they run pretty fast these days. You can use JDBC and get good performance. The biggest thing you lose with JDBC over the native VoltDB clients is better cluster awareness. In our native client you can get callbacks when servers fail, when backpressure is triggered, etc… Now Hibernate over JDBC is another issue. Edit: As merb points out JDBC is synchronous. This is true; if you have one client and one thread, this will be limiting fast. It's not a server-side issue though. If you have enough clients and/or enough threads, then you can still get very high throughput.
- mdellabitta 10y agoI see, I was reacting to the slide that mentioned ODBC and JDBC are slow. It makes sense that no matter the context, forcing the DB engine to parse and plan SQL it hasn't seen before could be quite a bit slower than parsing/planning it once and swapping in new parameters for each query.
- merb 10y agoActually JDBC is synchronous, this could be a real pain. But there are alternative's to most databases around.