+972 52-548-6969
RavenDB Conference videosKnow Thy Costs
In this talk from the RavenDB conference, Federico Lois is discussing the kind of performance work and optimizations that goes into RavenDB.
Performance happens. Whether you're designed for it or not it doesn’t matter, she is always invited to the party (and you better find her in a good mood). Knowing the cost of every operation, and how it distributes on every subsystem will ensure that when you are building that proof-of-concept (that always ends up in production) or designing the latest’s enterprise-grade application; you will know where those pesky performance bugs like to inhabit. In this session, we will go deep into the inner working of every performance sensitive subsystem. From the relative safety of the client to the binary world of Voron.
More posts in "RavenDB Conference videos" series:
- (03 Mar 2017) Replication changes in 3.5
- (01 Mar 2017) Delving into Documents with Data Subscriptions
- (27 Feb 2017) Building Codealike
- (23 Feb 2017) Implementing CQRS and Event Sourcing with RavenDB
- (21 Feb 2017) Zapping ever faster
- (17 Feb 2017) Should I use a document database?
- (15 Feb 2017) Know Thy Costs
- (13 Feb 2017) Lessons from the Trenches
- (09 Feb 2017) RavenDB Embedded at Massive Scales
- (07 Feb 2017) RavenDB for the Modern Web Developer
- (03 Feb 2017) Introducing RavenDB 4.0
- (01 Feb 2017) Introducing RavenDB 3.5
Comments
Off topic, but to show how far things have come in 6 years, look at this question from 2011: http://stackoverflow.com/questions/4011956/single-fixed-table-with-multiple-columns-vs-flexible-abstract-tables/42263010
Then just look at the first answer, which is the highest rated. Just look at it.
Then look into the comments on that answer: "A formal IT degree from a good Uni is the best place to start." Words fail me.
I had to add a nosql suggestion in case some poor earnest fellow would seriously think those ideas are practical or relevant.
Peter, I started reading the answer, and I literally got lost in the details and the complexity. Take into account that I used to make a full time living off of NHibernate and relational databases, and this is utterly crazy complex to go to that level to solve something so basic.
Comment preview