1) RDI uses RavenDB embedded in over 36,000 restaurants with around 500,000 individual machines processing $50,000 per second in payments.
2) RavenDB allows for unit testing without mocking the database, advanced statistics on data persistence, and transparent replication with high availability.
3) The challenges of using RavenDB on specialized older hardware with low memory and ESENT include fine-tuning memory usage, disabling caching, and automating recovery from unclean shutdowns with ESENTUTL.EXE.
2. ABOUT ME
Rodrigo Rosauro, Software Architect Manager at RDI
• Technology passionate
• Developer
• 14 years of experience in software development
• Working with RavenDB since 2013
3. ABOUT RDI
• We make restaurant automation software for QSR
• Our software runs on more than 36K restaurants
• Estimated number of individual machines: around half a million
• Processing almost USD $50K per second of customer payments
4. “ONE IN A MILLION IS NEXT TUESDAY”
- Gordon Letwin, Architect for DOS 4
5. HOW WE USED TO PERSIST DATA ON POS
... and still do (on legacy modules)
6. LEGACY PERSISTENCY
• Flat files
• Custom data format
• Event sourcing persistence
• Rebuild in-memory state at
every restart
7. PROBLEMS WITH THAT APPROACH
•No querying – at all
•High complexity to store new data
•No standard data format
•Lack of management tools
9. WHY A DBMS?
• We started a full re-architecture of the POS platform
• We are definitely not database/persistence specialists
• We wanted to remove complexity to persist data
11. GOALS / GUIDELINES
• The new architecture is based on plug-ins, so we wanted each
individual plug-in to have its own, isolated, database
• Zero administration
• Easy schema upgrades
• Transparent replication
• Unit tests
15. RAVENDB AT RDI
• Create unit tests without mocking the database
• Have advanced statistics about the data persistence
• Both system-wide and per plug-in
• Transparent replication
• Hot failover, data distribution & real-time backups
• Transparent encryption of data at rest
18. SPECIALIZED, OLD HARDWARE
Old hardware (sometimes 10 years old) means that we have very little
memory and processing power.
19. MEMORY CONSTRAINTS
• Many iterations with the RavenDB support team to fine-tune its memory
usage
• We learned that under these constraints, caching can be evil
• In the end, the solution was to completely disable caching on RavenDB and
do some cache at the application side, only for the “hot” data.
21. WE ARE STILL USING RAVENDB 2.5
• Our software must support Windows XPe
• .NET 4.0
• 32 bits machines
• … this means that ESENT is our only option for now
22. FACT: WE DON’T LIKE ESENT
(at least not for our usage scenarios)
23. WHY?
• Any unclean shutdown may cause a completely undetermined result
• Power outages / Application crashes / Task kill
• The possible results are not easy to find out during regular testing
• Crappy hardware doesn’t help
• We still face sporadic full database losses with ESENT
• Copying data between OS versions is awful
• Recovering from most unclean shutdowns requires using ESENTUTL.EXE
24. ESENTUTL.EXE
• We also hate don’t like ESENTUTL.EXE
• Many different commands to attempt to recover from different kinds of
unclean shutdowns. Some have different syntax on different OS versions
• We had to automate all that (zero maintenance, remember?)
• Almost 500 lines of code
25. “SUCCESS IS STUMBLING FROM FAILURE TO
FAILURE WITH NO LOSS OF ENTHUSIASM”
― Winston S. Churchill, Ex-prime minister of UK
27. THE FUTURE
• Working with Hibernating Rhinos to improve Voron to our use case
• 32 bits support
• Better reliability on unclean shutdowns
• We may jump straight to RavenDB 4.0 & CoreCLR
• Long-term target: Around 250K individual POS nodes running RavenDB
embedded
