{"id":1869,"date":"2012-12-27T15:45:34","date_gmt":"2012-12-27T15:45:34","guid":{"rendered":"http:\/\/www.odbms.org\/blog\/?p=1869"},"modified":"2014-06-05T15:37:36","modified_gmt":"2014-06-05T15:37:36","slug":"in-memory-oltp-database-interview-with-asa-holmstrom","status":"publish","type":"post","link":"https:\/\/www.odbms.org\/blog\/2012\/12\/in-memory-oltp-database-interview-with-asa-holmstrom\/","title":{"rendered":"In-memory OLTP database. Interview with Asa Holmstrom."},"content":{"rendered":"

“Those who claim they can give you both ACID transactions and linearly scalability at the same time are not telling the truth because it is theoretically proven impossible”<\/em> –Asa Holmstrom.<\/strong><\/p>\n

I heard about a start up called Starcounter<\/a>. I wanted to know more. I have interviewed the CEO of the company Asa Holmstrom<\/strong>.<\/p>\n

RVZ<\/p>\n

Q1. You just launched Starcounter 2.0 public beta. What is it? and who can already use it?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: Starcounter is a high performance in-memory OLTP database. We have partners who built applications on top of Starcounter, e.g. AdServe application, retail application. Today Starcounter has 60+ customers using Starcounter in production.<\/p>\n

Q2. You define Starcounter as “memory centric”, using a technique you call “VMDBMS”. What is special about VMDBMS?
\n<\/strong><\/p>\n

Asa Holmstrom<\/strong>: VMDBMS integrates the application runtime virtual machine (VM) with the database management system (DBMS). Data only residees in one single place all the time in RAM, no data is transferred back and forth between the database memory and the temporary storage (object heap) of the application. The VMDBMS makes Starcounter significantly faster than other in-memory databases.<\/p>\n

Q3. When you say “the VMDBMS makes Starcounter significantly faster than other in-memory databases”, could you please give some specific benchmarking numbers? Which other in-memory databases did you compare with your benchmark?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: In general we are 100 times faster than any other RDBMS, 10 times comes from being IMDBMS, 10 times comes from VMDBMS.<\/p>\n

Q4. How do you handle situations when data in RAM is no more available due to hardware failures?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: In Starcounter the data is just as secure as in any disk-centric database. Image files and transaction log are stored on disk, and before a transaction is regarded committed it has been written to the transaction log.
\nWhen restarting Starcounter after a crash, a recovery of the database will automatically be done. To guarantee high availability we recommend our customers to have a hot stand-by machine which subscribes on the transaction log.<\/p>\n

Q5. Goetz Graefe, HP fellow, commented in an interview (ref.1) that “disks will continue to have a role and economic value where the database also contains history, including cold history such as transactions that affected the account balances, login & logout events, click streams eventually leading to shopping carts, etc.” What is your take on this?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: As we have hardware limitations on RAM databases in practice about 2TB, therefore there will still be a need for database storage on disk.<\/p>\n

Q6. You claim to achieve high performance and consistent data. Do you have any benchmark results to sustain such a claim?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: Yes, we have made internal benchmark tests to compare performance while keeping data consistent.<\/p>\n

Q7: Do you have some results of your benchmark tests publically available? If yes, could you please summarize here the main results?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: As TPC tests are not applicable to us, we have done some internal tests. We can’t share them with you.<\/p>\n

Q8. What kind of consistency do you implement?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: We support true ACID consistency, implemented using snapshot isolation and fake writes, in a similar way as Oracle.<\/p>\n

Q9. How do you achieve scalability?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: ACID transactions are not scalable. All parallel ACID transactions need to be synchronized and the closer the transactions are executed in space, the faster the synchronization becomes. Therefore you get best performance by executing all ACID transactions on one machine. We call it to scale in. When it comes to storage, you scale up a Starcounter database by adding more RAM.<\/p>\n

Q10: For which class of applications it is realistic to expect to execute all ACID transactions on one machine?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: For all applications when you want high transactional throughput. When you have parallell ACID transactions you need to synchronize these transactions, and this synchorinization becomes harder when you scale out to several different machines. The benefits of scaling out grows linearly with the number of machines, but the cost of synchronization grows quadratically. Consequently you do not gain anything by scaling out. In fact, you get better total transactional throughput by running all transaction in RAM on one machine, which we call to “scale in”. No other databas can give you the same total ACID transactional throughput as Starcounter. Those who claim they can give you both ACID transactions and linearly scalability at the same time are not telling the truth because it is theoretically proven impossible. Databases which can give you ACID transaction or linearly scalablity
\ncannot give you both these things at the same time.<\/p>\n

Q11. How do you define queries and updates?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: We distinguish between read-only transactions and read-write transactions. You can only write (insert\/update) database data using a read-write transaction.<\/p>\n

Q12. Are you able to handle Big Data analytics with your system?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: Starcounter is optimized for transactional processing, not for analytical processing.<\/p>\n

Q13. How does Starcounter differs from other in-memory databases, such as for example SAP HANA, and McObject?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: In general the primary differentiator between Starcounter and any other in-memory database is the VMDMBS. SAP HANA has primarily an OLAP focus.<\/p>\n

Q14. From a user perspective, what is the value proposition of having a VMDMBS as a database engine?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: Uncompetable ACID transactional performance.<\/p>\n

Q15. How do you differentiate with respect to VoltDB?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: Better ACID transactional performance. VoltDB gives you either ACID transactions (on one machine) or the possibility to scale out without any guarantees of global database consistency (no ACID). Starcounter has a native .Net object interface which makes it easy to use from any .Net language.<\/p>\n

Q16. Is Starcounter 2.0 open source? If not, do you have any plan to make it open source?<\/strong><\/p>\n

Asa Holmstrom<\/strong>: We do not have any current plans of making Starcounter open source.<\/p>\n

——————
\nCEO Asa Holmstrom<\/strong> brings to her role at Starcounter<\/a> more than 20 years of executive leadership in the IT industry. Previously, she served as the President of Columbitech, where she successfully established its operations in the U.S. Prior to Colmbitech, Asa was CEO of Kvadrat, a technology consultancy firm. Asa also spent time as a management consultant, focusing on sales, business development and leadership within global technology companies such as Ericsson and Siemens. She holds a bachelor’s degree in mathematics and computer science from Stockholm University.<\/em><\/p>\n

Related Posts<\/strong><\/p>\n

– Interview with Mike Stonebraker. by Roberto V. Zicari on May 2, 2012<\/a><\/strong><\/p>\n

– In-memory database systems. Interview with Steve Graves, McObject. by Roberto V. Zicari on March 16, 2012<\/a><\/strong><\/p>\n

(ref. 1)<\/strong><\/em>– The future of data management: \u201cDisk-less\u201d databases? Interview with Goetz Graefe. by Roberto V. Zicari on August 29, 2011<\/a><\/strong><\/p>\n

Resources<\/strong><\/p>\n

– Cloud Data Stores – Lecture Notes: Data Management in the Cloud.<\/a> <\/strong>
\nby Michael Grossniklaus, David Maier, Portland State University.<\/strong>
\nCourse Description<\/strong>: “Cloud computing has recently seen a lot of attention from research and industry for applications that can be parallelized on shared-nothing architectures and have a need for elastic scalability. As a consequence, new data management requirements have emerged with multiple solutions to address them. This course will look at the principles behind data management in the cloud as well as discuss actual cloud data management systems that are currently in use or being developed.
\nThe topics covered in the course range from novel data processing paradigms (MapReduce, Scope, DryadLINQ<\/strong>), to commercial cloud data management platforms (Google BigTable, Microsoft Azure, Amazon S3 and Dynamo, Yahoo PNUTS<\/strong>) and open-source NoSQL databases (Cassandra, MongoDB, Neo4J<\/strong>).
\nThe world of cloud data management is currently very diverse and heterogeneous. Therefore, our course will also report on efforts to classify, compare and benchmark the various approaches and systems.
\nStudents in this course will gain broad knowledge about the current state of the art in cloud data management and, through a course project, practical experience with a specific system.”
\nLecture Notes | Intermediate\/Advanced | English |<\/strong> DOWNLOAD ~280 slides (PDF)<\/a><\/strong>| 2011-12|<\/strong><\/p>\n

##<\/p>\n","protected":false},"excerpt":{"rendered":"

“Those who claim they can give you both ACID transactions and linearly scalability at the same time are not telling the truth because it is theoretically proven impossible” –Asa Holmstrom. I heard about a start up called Starcounter. I wanted to know more. I have interviewed the CEO of the company Asa Holmstrom. RVZ Q1. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[6,47,223,276,516,549,554,616],"_links":{"self":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/1869"}],"collection":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/comments?post=1869"}],"version-history":[{"count":1,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/1869\/revisions"}],"predecessor-version":[{"id":3322,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/posts\/1869\/revisions\/3322"}],"wp:attachment":[{"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/media?parent=1869"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/categories?post=1869"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.odbms.org\/blog\/wp-json\/wp\/v2\/tags?post=1869"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}