4 ms·

Sounds nice. Some questions: - I assume you did the tests with direct SQL statements without any ORM? How would an ORM affect the test's performance (with an N

by tferris 15y ago

Sounds nice. Some questions: - I assume you did the tests with direct SQL statements without any ORM? How would an ORM affect the test's performance (with an Node.JS-ORM of your choice, e.g. sequelize)? - How does Node+VoltDB compare to i.e. Node+PostgreSQL or Node+MySQL - What does in memory SQL exactly mean? How is data made persistent?

tferris 15y ago
Just read this on VoltDB's site: "Third is NewSQL, which obtains better performance and scale in the only way possible – with a totally new architecture. NewSQL delivers high performance and scalability while preserving the traditional ACID functions needed for OLTP. NewSQL systems like VoltDB deliver better throughput than NoSQL without requiring transactions to be supported in user code. NewSQL systems also preserve the high-level language capabilities of SQL." How does this work?
- MichaelGG 15y ago
  Read the H-Store publications[1], which served as the starting point for Volt. Basically, by staying in memory and eliminating locking, you get awesome performance. However, why should you have to give up SQL, tables, and transactions? Those things make developing apps easy. So why not get "NoSQL-like" performance, but keeping the good parts of "SQL"? 1: http://hstore.cs.brown.edu/publications/ http://hstore.cs.brown.edu/publications/
  - MSM 15y ago
    After looking around I'm still not sure what they mean by 'eliminating locking'. Locking isn't just overhead, it's needed for transactions- how are transactions handled if there is no locking? Does the speed come at the cost of dirty reads and writes?
    - benmmurphy 15y ago
      I think they partition the data then serialize access in the partition. Makes things very fast assuming you only need to modify stuff atomically in one partition.
    - jhugg 15y ago
      VoltDB achieves concurrency via scheduling, rather than shared access to data structures. There are concurrency primitives around networking/messaging and transaction scheduling, so there aren't truly ZERO locks in the system as a whole. The big difference is that VoltDB has zero system-locks (mutexes,etc) around table data and indexes. It also has no logical locks/latches arounds indexes and rows like other systems. This makes executing SQL very fast. Because it doesn't wait on disk or on mutexes, SQL execution is typically bottlenecked on memory bandwidth.
MichaelGG 15y ago
VoltDB doesn't really support ad-hoc SQL. It can execute ad-hoc by flipping a flag, but performance is achieved by using stored procedures. You write the sprocs in Java, and their compiler looks at the SQL statements and optimizes. VoltDB smokes other RDBMS (Postgres, MySQL, MSSQL, etc.) for certain OLTP workloads because it stays purely in-memory, but removes all locking. Normal databases spend a huge amount of time dealing with locks, even if the memory is in RAM. VoltDB was based on the H-Store project; you can read more about the ideas at [1]. Making transactions execute serially[2] adds latency to an individual transaction, but the point with VoltDB is to send tons of transactions so that there's always work queued up. You should be able to get average latency of, say, 10ms for the type of app mentioned here. I'm surprised it's not mentioned in the blog post. (Maybe on EC2, the latency numbers were less-than-ideal, but throughput was fine.) SQL and ACID have nothing to do with the backing store. Using RAM is just as valid as using disk. Practically, with VoltDB you're going to set the "k factor" - number of replicas you want. This allows you to lose k servers without suffering data loss (put batteries on the servers; that should be pretty good). There's a snapshot backup feature, and the enterprise edition has a disk logger to further minimize the loss window in case of catastrophic failure. 1: http://hstore.cs.brown.edu/publications/ http://hstore.cs.brown.edu/publications/ 2: More or less. Servers are sync'd via NTP, allowing one to know when it's safe to run a specific transaction. There's also some ways Volt might know when one tx is independent and safe to run before another.
- jhugg 15y ago
  To update what you've said with insider info, ad-hoc SQL performance is currently a big focus at VoltDB. We fully support ad-hoc access in auto-commit mode through our native clients or through JDBC. Currently, we can do hundreds or thousands of statements/sec, and we expect performance to increase dramatically in the next few months. Here's the Epic in JIRA: https://issues.voltdb.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=cf%5B10021%5D+%3D+ADHOC https://issues.voltdb.com/secure/IssueNavigator.jspa?reset=t... Typically, applications are not 100% ad-hoc on VoltDB, but we're starting to see more hybrid use cases. Stored procedures can be used for extreme throughput or for transactional requirements, but other parts of the app can be more flexible.
- pron 15y ago
fredholahan 15y ago
A few answers: Yes, the tests were run without an ORM. Although VoltDB is accessible via JDBC, best throughput is achieved with parameterized SQL embedded in Java stored procedures. That's how the Node.js benchmark app (Voter) was implemented. Node+Volt will be much faster than Node+Postgres or Node+MySQL for many OLTP-style workloads. So it's a great fit for apps like financial trading, digital advertising, online gaming and network monitoring - each of which requires super-high throughput writes (at single ms latencies) and fast, simple analytics. Node+Postgres or Node+MySQL would be a better fit for general purpose database workloads (e.g., with large-grained reporting). In-memory means that Volt stores all data in main memory. Durability is achieved through the use of a highly innovative command log, which logs all transaction invocations to persistent storage. You can tune this feature to log synchronously (100% guaranteed durability at reduced transaction latency) or asynchronously (slightly more "lossy", but less of a latency impact). VoltDB also recently released a full database replication feature that supports WAN replication for disaster recovery. I hope these responses are in some way helpful.
- MichaelGG 15y ago
  What were the latency statistics? How good of time sync were you able to get the EC2 instances?
  - aweisberg 15y ago
    The intent of the test was to measure throughput. Since the API is asynchronous that means the client was submitting as much work as would fit in the queues at both client and server and any latency measurement would be a measurement of how long it takes to execute all queued requests in the pipeline and the pipeline is always kept full. I am able to get sub-millisecond offsets (as reported by ntpq -p) with m1.large instances, but I have never left them running long. I am not sure what Henning got when he ran. I pointed him to my blog post on the topic http://www.afewmoreamps.com/2011/07/configuring-ntp-for-voltdb.html http://www.afewmoreamps.com/2011/07/configuring-ntp-for-volt... On bare metal ntpdate reports offsets that are sub microsecond. I find that nodes sync up quickly if only one of them polls the public pool.
  - 15y ago

by tferris 15y ago

tferris 15y ago

Just read this on VoltDB's site: "Third is NewSQL, which obtains better performance and scale in the only way possible – with a totally new architecture. NewSQL delivers high performance and scalability while preserving the traditional ACID functions needed for OLTP. NewSQL systems like VoltDB deliver better throughput than NoSQL without requiring transactions to be supported in user code. NewSQL systems also preserve the high-level language capabilities of SQL." How does this work?

MichaelGG 15y ago
Read the H-Store publications[1], which served as the starting point for Volt. Basically, by staying in memory and eliminating locking, you get awesome performance. However, why should you have to give up SQL, tables, and transactions? Those things make developing apps easy. So why not get "NoSQL-like" performance, but keeping the good parts of "SQL"? 1: http://hstore.cs.brown.edu/publications/ http://hstore.cs.brown.edu/publications/
- MSM 15y ago
  After looking around I'm still not sure what they mean by 'eliminating locking'. Locking isn't just overhead, it's needed for transactions- how are transactions handled if there is no locking? Does the speed come at the cost of dirty reads and writes?
  - benmmurphy 15y ago
    I think they partition the data then serialize access in the partition. Makes things very fast assuming you only need to modify stuff atomically in one partition.
  - jhugg 15y ago
    VoltDB achieves concurrency via scheduling, rather than shared access to data structures. There are concurrency primitives around networking/messaging and transaction scheduling, so there aren't truly ZERO locks in the system as a whole. The big difference is that VoltDB has zero system-locks (mutexes,etc) around table data and indexes. It also has no logical locks/latches arounds indexes and rows like other systems. This makes executing SQL very fast. Because it doesn't wait on disk or on mutexes, SQL execution is typically bottlenecked on memory bandwidth.

MichaelGG 15y ago

VoltDB doesn't really support ad-hoc SQL. It can execute ad-hoc by flipping a flag, but performance is achieved by using stored procedures. You write the sprocs in Java, and their compiler looks at the SQL statements and optimizes. VoltDB smokes other RDBMS (Postgres, MySQL, MSSQL, etc.) for certain OLTP workloads because it stays purely in-memory, but removes all locking. Normal databases spend a huge amount of time dealing with locks, even if the memory is in RAM. VoltDB was based on the H-Store project; you can read more about the ideas at [1]. Making transactions execute serially[2] adds latency to an individual transaction, but the point with VoltDB is to send tons of transactions so that there's always work queued up. You should be able to get average latency of, say, 10ms for the type of app mentioned here. I'm surprised it's not mentioned in the blog post. (Maybe on EC2, the latency numbers were less-than-ideal, but throughput was fine.) SQL and ACID have nothing to do with the backing store. Using RAM is just as valid as using disk. Practically, with VoltDB you're going to set the "k factor" - number of replicas you want. This allows you to lose k servers without suffering data loss (put batteries on the servers; that should be pretty good). There's a snapshot backup feature, and the enterprise edition has a disk logger to further minimize the loss window in case of catastrophic failure. 1: http://hstore.cs.brown.edu/publications/ http://hstore.cs.brown.edu/publications/ 2: More or less. Servers are sync'd via NTP, allowing one to know when it's safe to run a specific transaction. There's also some ways Volt might know when one tx is independent and safe to run before another.

jhugg 15y ago
To update what you've said with insider info, ad-hoc SQL performance is currently a big focus at VoltDB. We fully support ad-hoc access in auto-commit mode through our native clients or through JDBC. Currently, we can do hundreds or thousands of statements/sec, and we expect performance to increase dramatically in the next few months. Here's the Epic in JIRA: https://issues.voltdb.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=cf%5B10021%5D+%3D+ADHOC https://issues.voltdb.com/secure/IssueNavigator.jspa?reset=t... Typically, applications are not 100% ad-hoc on VoltDB, but we're starting to see more hybrid use cases. Stored procedures can be used for extreme throughput or for transactional requirements, but other parts of the app can be more flexible.
pron 15y ago

fredholahan 15y ago

A few answers: Yes, the tests were run without an ORM. Although VoltDB is accessible via JDBC, best throughput is achieved with parameterized SQL embedded in Java stored procedures. That's how the Node.js benchmark app (Voter) was implemented. Node+Volt will be much faster than Node+Postgres or Node+MySQL for many OLTP-style workloads. So it's a great fit for apps like financial trading, digital advertising, online gaming and network monitoring - each of which requires super-high throughput writes (at single ms latencies) and fast, simple analytics. Node+Postgres or Node+MySQL would be a better fit for general purpose database workloads (e.g., with large-grained reporting). In-memory means that Volt stores all data in main memory. Durability is achieved through the use of a highly innovative command log, which logs all transaction invocations to persistent storage. You can tune this feature to log synchronously (100% guaranteed durability at reduced transaction latency) or asynchronously (slightly more "lossy", but less of a latency impact). VoltDB also recently released a full database replication feature that supports WAN replication for disaster recovery. I hope these responses are in some way helpful.

MichaelGG 15y ago
What were the latency statistics? How good of time sync were you able to get the EC2 instances?
- aweisberg 15y ago
  The intent of the test was to measure throughput. Since the API is asynchronous that means the client was submitting as much work as would fit in the queues at both client and server and any latency measurement would be a measurement of how long it takes to execute all queued requests in the pipeline and the pipeline is always kept full. I am able to get sub-millisecond offsets (as reported by ntpq -p) with m1.large instances, but I have never left them running long. I am not sure what Henning got when he ran. I pointed him to my blog post on the topic http://www.afewmoreamps.com/2011/07/configuring-ntp-for-voltdb.html http://www.afewmoreamps.com/2011/07/configuring-ntp-for-volt... On bare metal ntpdate reports offsets that are sub microsecond. I find that nodes sync up quickly if only one of them polls the public pool.
- 15y ago