New answers tagged nosql
You can run a --repairDatabase for that node: mongod --repair --repairpath <repair_path> Keep in mind that the repair path should have at least as your data size free disk space. (if you have 100GB, the repair path should have at least 100GB free also. That should take care of problems of that sort. Also, in the future if anything of some sort ...
You should go with mongoDB. My recommendation is to create a sharded environment using as shard key the restaurant identifier - i guess most of your queries will include that.
This is almost certainly memory fragmentation, as redis is well-known and loved in production and you probably haven't found a memory leak. The recommendations about setting the size of the pool won't help fragmentation. You'll have to specifically lower the Redis size - lower than your actual memory size - because Redis can't account for fragmentation - ...
I would imagine that you would be querying the log collection based on username, so it should be fine to create a single collection for the logs. The reason I wouldn't suggest nesting log documents is that there is a limit on document size. If you know your query pattern is name and date then it should work out pretty well. Can I ask what the "noSQL way ...
Are there any benefits in disabling mongodb journaling besides performance gain? The only other marginal benefit is if you are using a 32-bit build (which is also not recommended for production use). Since 32-bit builds are limited to ~2Gb of addressable data for memory mapped files, the journal is off by default to allow for more data (with journal ...
cqlsh -k mykeyspace -e 'COPY fromTable(columnNames) TO STDOUT' | head -n -1 | cqlsh -k mykeyspace -e 'COPY toTable(columnNames) FROM STDIN'
MongoDB's dynamic schema supports different fields for documents within the same collection, so there is no strict requirement for all documents to have an active field. The main consideration here will be how that affects your application logic; it may be simpler to have an explicit field present and check the value. If you have an index on a field, ...
In addition to what @jynus has written above - check out my answer to a similar question here (see reference to Celko). Furthermore, the MySQL ENUM type should be avoided for many reasons - 8 reasons as to why they are "evil" can be found here.
I recommend you to read about the dangers of the Entity-Attribute-Value pattern on this presentation by @Bill Karwin. One of the solutions is storing NoSQL-like data in a serialized BLOB, if you do not need to read and write individual properties. That is, storing a key (product) as the primary key, and the variable property-value pairs all together in a ...
Top 50 recent answers are included