3 ms·
I apologize, because I literally don't know, but have you used any of these solutions at the scale where there might be billions or trillions of rows in a table
by trashcan 6y ago
I apologize, because I literally don't know, but have you used any of these solutions at the scale where there might be billions or trillions of rows in a table/collection? I'm currently using Mongo at that scale and would love to evaluate some alternatives.
If it helps for context, we have accepted that ad-hoc queries are not possible, and we have our own solution for searching.
- jinqueeny 6y agoTiDB has a similar case study: Queries over 1.3 Trillion Rows of Data Within Milliseconds of Response Time at Zhihu.com https://pingcap.com/success-stories/lesson-learned-from-queries-over-1.3-trillion-rows-of-data-within-milliseconds-of-response-time-at-zhihu/ https://pingcap.com/success-stories/lesson-learned-from-quer... The latest stats in the same case scenario (already-read posts) Zhihu is: - 2.6 Trillion Rows - 560TB data - 200 TiKV instances
- trashcan 6y agoVery cool! Thanks, I will look into it.
- manigandham 6y agoWe used MemSQL with 100s of billions of rows for years in production. If you're working at that scale, it sounds like that's more of an OLAP use-case where MemSQL and other column-oriented databases would suit better than an OLTP document-store. Maybe you can share more details for better recommendations.