Database
6 results found
-
Additional checks for storage consistency
The following opt-in features would add additional check to check for storage layer corruptions of collections.
- Upon write read what data was committed to disk.
- Periodic or scheduled scanning of a collection. Similar to collection.validate but non blocking.
11 votes -
wired
wiredTiger open files usage
Currently WT uses a file per collection and index, leading in some scenarios to extremely high number of open files/dhandles.
Is there any plan to support one file/dhandle per database?
4 votes -
Enable BigInt Support for Blockchain Use
Smart contracts on Ethereum and on Ethereum compatible chains are represented as 256bit integers. There are several libraries widely used to deal with these data types in JavaScript such as bn.js and BigNumber.js.
A potential workaround could be to split the data, store using Decimal128, and recombine using Aggregation Framework. However, this would add performance and programming overhead that encourages customers to select alternatives to MongoDB.
3 votes -
Allow changing compression of an existing collection
I'd like to switch my database from Snappy to Zstd compression.
Currently, it doesn't seem that it is possible to change the compression of an existing collection.
It would be nice if there were a way to do this, even if (for example) it required making a new replica set member which "re-compresses" the data to the new algorithm while cloning it.
As per SERVER-67726, the only way to do this today is to create a new collection and manually copy with mongodump/mongorestore. This doesn't seem to be a viable option, for uptime / data consistency reasons.
3 votes -
Easier way to troubleshoot storage use size discrepancy across nodes in the same replica set
While initial sync may potentially help on this topic, it would be great if the product has any easier way to identify the cause of significantly different storage use size (so to give a better confidence if initial sync is going to help).
1 vote -
Allow disabling auto removal for capped collections
Capped collections work as a circular buffer - when adding new documents after the size limit is reached, old documents are removed.
I would like to have an option for the collection, where this behavior can be changed - instead of removing old documents, the insert should fail with a specific error (eg: collection full). This would allow implementing log-rotation, by creating a new collection whenever the old one is full.
My motivation:
I have two services, one creating documents (events), and another one processing them. I'm looking for a reliable way to:
- process all documents from start, without…1 vote
- Don't see your idea?