Tag Info

Hot answers tagged

14

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 ...


12

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 ...


10

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.


5

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 +--------------+ | ...


4

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 ...


2

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. ...


1

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.


1

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. ...


1

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 ...


1

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 ...


1

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


1

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 ...



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