Tag Info

Hot answers tagged


Horizontal Scaling Horizontal Scaling is essentially building out instead of up. You don't go and buy a bigger beefier server and move all of your load onto it, instead you buy 1+ additional servers and distribute your load across them. Horizontal scaling is used when you have the ability to run multiple instances on servers simultaneously. Typically it is ...


IMO you are making what is probably a pretty common mistake when it comes to web pages which is to assume that the answer to performance problems due to initial result size on MySQL is to jump to NoSQL solutions often with little understanding of what the tradeoffs are or how to use them appropriately and effectively. I would be surprised if a well-tuned db ...


There are a lot of differences between the two of them. MongoDB is more like a traditional RDBMS (nobody shoot). CouchDB performs master-master replication. It's pretty well documented in this much ballyhooed blog post.


You can store your index as a list of fixed-size offsets into the block containing your key data. For example: +--------------+ | 3 | number of entries +--------------+ | 16 | offset of first key data +--------------+ | 24 | offset of second key data +--------------+ | 39 | offset of third key data +--------------+ | ...


PM from Couchbase here. We've actually been working on an embedded NoSQL database for mobile dubbed "Couchbase Lite" (in parallel with SQL and SQLite) that plays exactly into the scenario you are describing. The idea is to provide your application with a JSON-based database that can: Opportunistically sync to a backend cluster as needed Utilize our ...


I think the answer mainly depends on how much time do you want to spend learning new databases vs how much time to you want to spend learning machine learning. For example PostgreSQL has lots of GIS stuff built-in which I assume could be very useful for your queries. CouchDB has many useful features with their map/reduce stuff but I find it a bit limited. ...


During compaction, a new .couch file is written. So what you would do, when you interrupt compaction is making the file useless. The only way to stop compaction (iirc) is to stop CouchDB. Not a good idea. Generally, compaction is a background process. The database reads are not affected by it - also for heavy read! If you have heavy write processes, ...


Ok, I found the solution, I have to use the reduce function for that, like: function(keys, values, rereduce){ var result = null; var orders = [] for(var i =0; i< values.length; i++){ if(values[i].type=='customer') result = values[i]; else{ orders.push(values[i]) } } result.orders = orders; return result; }


Per this StackOverflow thread, it sounds like lists are created by serializing and then deserializing the data. If you were deeply nesting your documents with list inside of list, that would be a serious performance hit purely from the serialization and deserialization. If you have a hierarchy like this, I would consider using MySQL, since it's designed ...


It's best not to use the name of a "type" as an id - it is better to use generated id's and have a key called "type" in each document where you have a string value of "Home" etc


Couchbase includes a built-in cache as a part of the database instance (that's based on memcached technology), which makes it a great choice for a distributed caching tier, key value use cases or document-driven use cases. Large customers like Orbitz use Couchbase as a distributed caching tier. This page may give you addition information you are looking for. ...


Both are currently evolving, so if you chose one today, you may find that you need to switch later. I know of a company that did a thorough review of both, with prototype apps implemented in both, and they made a well-informed choice based on the project requirements. Initially, they had success with their choice, but after about 6 months, some of the ...


As a MySQL DBA staring at this, I think in relational terms. I also think in terms of doing JOINs. However, from a NoSQL standpoint, JOINs would have to be done programmatically. Multiple documents, one for each ingredient : This will make smallest amount of static data to place in collections. Yet, you should be prepared for getting references, building ...


Normally you should never do so because other revisions may be deleted after compacting the database. You should include all necessary fields to recompose(reprint) the invoice in the invoice document, like: product description, product price, total, and so on. This is the same if you would store invoices in a rdbms.


Are you sure you have the right idea what a database actually is? Frankly, your idea with setting up 88 databases doesn't sound like it. A regular approach to your problem would be splitting the CSV data into regular columns (first_name, last_name etc.) and then using an index on those columns to find data reasonably quickly.


This is caused by Nagle's algorithm. CouchDB sends the HTTP headers and the response body in separate calls, causing the kernel to not deliver the response body for 40ms. As a workaround, you can use this LD_PRELOAD shim to completely turn off Nagle's algorithm for the database process.


You can validate the input by adding another entity "validate_doc_update" to the _design/ document.The validate_doc_update function gets executed for each document you want to create or update. If the validation function raises an exception, the update is denied; when it doesn’t, the updates are accepted. It is optional i.e. if you do not write one, no ...

Only top voted, non community-wiki answers of a minimum length are eligible