News for hackers. Stuff that matters.
Re:MongoDB History by trashcan on Friday September 04, 2020 @08:24PM (#24380329)
> Also it was great at sharding and scaling horizontally when first released, and one of the few options available at that time. It's since been eclipsed by much better systems that don't have such a convoluted and fragile setup.

What applications are much better in your opinion?

Re:MongoDB History by manigandham on Sunday September 06, 2020 @09:14PM (#24395929)
I'd recommend sticking with relational databases since they all support JSON columns now. If you need horizontal scalability then there are many choices like CockroachDB, Yugabyte, TiDB, Vitesse, MemSQL, and others.

If still want a document-store then RavenDB is a great choice with proper clustering, full-text search, SQL-like querying, graph queries, etc. ArangoDB is also good choice.

Re:MongoDB History by trashcan on Sunday September 06, 2020 @11:59PM (#24396519)
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.

Re:MongoDB History by jinqueeny on Monday September 07, 2020 @01:15AM (#24396765)
TiDB 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-quer...

The latest stats in the same case scenario (already-read posts) Zhihu is:

- 2.6 Trillion Rows

- 560TB data

- 200 TiKV instances

Re:MongoDB History by trashcan on Monday September 07, 2020 @01:21AM (#24396782)
Very cool! Thanks, I will look into it.
Re:MongoDB History by manigandham on Tuesday September 08, 2020 @03:14AM (#24405935)
We 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.