Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I am looking at the IA for a hypothetical application scenario, for example:

  • A high demand application such as an online ticketing website where there can be demand for 100,000 tickets to be purchased per minute. At the same time the number of tickets needs to be tracked accurately so that they are not oversold (so I'm thinking to maintain the ticket count in memory).

I am thinking the less time critical tasks can be queued or deferred, ie email confirmation, and then write everything to the physical DB after the ticket purchase transaction is complete.

The only risk with in memory I believe is if the software/hardware fails, but I believe there may be some clustered options with some IMDB providers so that they are failsafe.

I have considered horizontal scaling/sharding with regular RDBMS but I am worried about the costs. I'd love to hear some thoughts if anybody has dealt with similar scenarios and if they used IMDB or something else?

share
    
Thanks for your input TomTom/Jon. If I were to say 10,000 transactions per second would this change the possible options. Would traditional RDBMs work for this? –  Dkong Jun 6 '13 at 17:23
    
You should check out VoltDB... –  user24729 Jun 7 '13 at 22:57
    
As is often the case with these shopping list questions, the vendors eventually start turning up to throw their advert into the answer list. VtC from me. –  Mark Storey-Smith Jun 7 '13 at 23:06
comments disabled on deleted / locked posts

migration rejected from stackoverflow.com Jun 8 '13 at 3:29

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as not constructive by Mark Storey-Smith, RolandoMySQLDBA, Aaron Bertrand Jun 8 '13 at 3:29

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers

While 100,000 transactions per minute sounds like a lot, it's generally classed as a "moderate" transaction rate (100,000 tx/min / 60 sec/min = 1,666.7 tx/sec).

There are systems out there running typical RDBMS systems (not in-memory) that can handle well over 10x that transaction rate (sustained) on a single box. Granted, these are well-tuned systems at both a hardware and software level, but if you want maximum performance, that's what you have to do. You don't want to be distributing the slow.

Any enterprise-grade RDBMS system coupled with a sound application design should be able to get to this goal, so I don't see a reason to complicate things unnecessarily.

Regarding your follow-up comment, IMO, your best bet performance-wise is to use a technology you're very familiar with. You'll always be able to better exploit that which you know, than that which you don't know. Once you've narrowed things down, create a proof-of-concept on each system, and try to make it scale. That's the only real way you'll be able to say whether or not a particular technology will work for the project.

share
add comment

Have you considered using a normal database?

I know of NO database (that is server grade - not some joke like MS Access) that does not utilize memory as cache as heavily as possibly. There is no need for an in memory database. Just make sure you have enough memory.

share
    
I'm with Tom on this. We run much higher than this on MS SQL Server but we have the RAM to handle it and the transaction log disks are optimized for this type of operation (8 disk 15k RPM RAID 10 + SAN level caching on that array). +1 –  Ali Razeghi Jun 6 '13 at 22:06
add comment

You should check out VoltDB. It can handle extremely high transaction rates (>100K txns/sec/server) with read or write-heavy workloads, full ACID-compliance, including full synchronous (immediate) durability and multi-statement transactions (e.g. check if seat is still available, then assign ticket in the same transaction).

Full disclosure: I work for VoltDB. We have sample applications you can download and hack apart to build a POC, and we'd be happy to help if you contact us.

share
    
Hi Ben, I have looked at VoltDB recently. I know it has some .NET class libraries but I am wondering if that has improved in recent times? –  Dkong Jun 7 '13 at 5:35
    
Thanks for making it clear you work for VoltDB, Ben, we much prefer that. –  Jack Douglas Jun 8 '13 at 4:29
    
Hi Dkong, the VoltDB .NET client library has been updated in the last few weeks to version 3.0. Here is the announcement, the download page, and the github repository voltdb-client-csharp if you'd like to review the details of the recently-committed changes. –  Ben Ballard Jun 10 '13 at 15:31
add comment

You may want to take a look at Altibase products. ALTIBASE HDB is a hybrid (in-memory + on-disk) DBMS and ALTIBASE XDB which is a pure in-memory DBMS. They are both full ANSI and ACID compliant databases, and they both deliver transaction speeds well over 100K TPS. XDB's performance can reach to an extreme number at 1.5 million TPS when client app is deployed in the same node as the database server. The trial version of HDB is available for downloads at Altibase website, and XDB trial version can be requested via email. I am an employee of Altibase.

share
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.