4 ms·

Seems related to your case study here: https://stratoflow.com/case_studies/highly-scalable-travel-search-engine-with-real-time-calculation-of-price-and-availabi

by tyingq 3y ago

Seems related to your case study here: https://stratoflow.com/case_studies/highly-scalable-travel-search-engine-with-real-time-calculation-of-price-and-availability/ https://stratoflow.com/case_studies/highly-scalable-travel-s... Basically, you worked with a hotel aggregator that happened to do direct SQL queries for searches. Then you migrated them to this pattern: "decided to extract the availability search into a separate cache layer based on in-memory data grid (IMDG) platform. This new solution holds in memory a complete set of data required to return a hotel availability information. We also implemented a custom, fast data loading mechanism to populate the memory grid from database as well as a message queue pipeline supporting incremental intraday data updates." So, putting something like Apache Ignite in place, with intraday updates. That's an improvement for the client, for sure. But, most hotel aggregators aren't doing live SQL queries against a single database. You happened to find a client that was at the tail end of figuring out that wouldn't scale for them. Any of them with serious volume is doing something similar where they keep the main relational database for data entry and updates. But the live search is done with ElasticSearch, Redis, Geode/Gemfire, Cassandra, plain old read replicas or some other tech that's better suited for the complex availability queries. And some mechanism for intraday updates.

mgl 3y ago
Hi tyingq, thank you for your comment. Your deduction goes a bit too far - yes, the technology demo in this post is in the same space as that case study, but no - the implementation is completely different. Many firms replace their in-database processing with in-memory-like stores but it would be very difficult to achieve similarly low latency and still provide real-time updates with the solutions that you mentioned like Redis, ElasticSearch, etc. due to a number of the internal design features of these data stores. The most fundamental issues are: a) inefficient memory allocation model hurting CPU cache usage, b) implementation model based on painful data serialization/deserialization transformations wasting both CPU and memory resources. This is why we build and share this demo which enables you to achieve a 20x lower latency than other available options. You may find a a bit more what's behind the demo in the Technology section here: https://ultrafastsearchengine.com/#/details https://ultrafastsearchengine.com/#/details
- tyingq 3y ago
  > You may find a a bit more what's behind the demo... That only says "the engine is a Java-based proprietary solution which was about 20x faster than comparable implementations in Coherence, Ignite or Hazelcast. (Yes, we tested it.)". So, comparable to those. Some sort of Java friendly in-memory cache. Perhaps, for this specific kind of data (dates/location/room-type/price/availability), you've figured out an optimal storage/retrieval layout that's fast. That seems plausible. What doesn't seem plausible is that your cache is generally 20x faster than every other cache in the space.
  - mgl 3y ago
    The combination of storage/retrieval/calculation, executed close to the actual data, is what gives 20x advantage. CPU cache is hard-to-believe fast, see: https://stratoflow.com/latency-numbers-every-java-developer-should-know/ https://stratoflow.com/latency-numbers-every-java-developer-...

by tyingq 3y ago

mgl 3y ago

Hi tyingq, thank you for your comment. Your deduction goes a bit too far - yes, the technology demo in this post is in the same space as that case study, but no - the implementation is completely different. Many firms replace their in-database processing with in-memory-like stores but it would be very difficult to achieve similarly low latency and still provide real-time updates with the solutions that you mentioned like Redis, ElasticSearch, etc. due to a number of the internal design features of these data stores. The most fundamental issues are: a) inefficient memory allocation model hurting CPU cache usage, b) implementation model based on painful data serialization/deserialization transformations wasting both CPU and memory resources. This is why we build and share this demo which enables you to achieve a 20x lower latency than other available options. You may find a a bit more what's behind the demo in the Technology section here: https://ultrafastsearchengine.com/#/details https://ultrafastsearchengine.com/#/details

tyingq 3y ago
> You may find a a bit more what's behind the demo... That only says "the engine is a Java-based proprietary solution which was about 20x faster than comparable implementations in Coherence, Ignite or Hazelcast. (Yes, we tested it.)". So, comparable to those. Some sort of Java friendly in-memory cache. Perhaps, for this specific kind of data (dates/location/room-type/price/availability), you've figured out an optimal storage/retrieval layout that's fast. That seems plausible. What doesn't seem plausible is that your cache is generally 20x faster than every other cache in the space.
- mgl 3y ago
  The combination of storage/retrieval/calculation, executed close to the actual data, is what gives 20x advantage. CPU cache is hard-to-believe fast, see: https://stratoflow.com/latency-numbers-every-java-developer-should-know/ https://stratoflow.com/latency-numbers-every-java-developer-...