Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
There is a lot of articles on the web supporting the trend to move to a graph database like Neo4j... but I can't find much against them.
When would a graph database not be the best solution?
Any links to articles that compare graphs, nosql, and relational databases would be great.
Currently I would not use Neo4j in a high volume write situation. The writes are still limited to a single machine, so you're restricted to a single machine's throughput, until they figure out some way of sharding (which is, by the way, in the works). In high volume write situations, you would probably look at some other store like Cassandra or MongoDB, and sacrifice other benefits a graph database gives you.
Another thing I would not currently use Neo4j for is full-text search, although it does have some built-in facility (as it uses Lucene for indexing under the hood), it is limited in scope and difficult to use from the latest Cypher. I understand that this is going to be improving rapidly in the next couple of releases, and look forward to that. Something like ElasticSearch or Solr would do a better job for FTS-related things.
Contrary to popular belief, tabular data is often well-fitted to the graph, unless you really have very denormalized data, like log records.
The good news is you can take advantage of many of these things together, picking the best tool for the job, and implement a polyglot persistence solution to answer your questions the best way possible.
Also, I would not use neo4j for serving and storing binary data. There are much better options for images, videos and large text documents out there - use them either as indexes with Neo4j, or just reference them.
When would a graph database not be the best solution?
When you work in a conservative company.
Insert some well thought-out technical reason here.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What is the best way of storing and querying data for a simple tasks management application (e.g.)? The goal is to have maximum performance with minimum resources consumption (CPU, disk, RAM) for a single EC2 instance.
This depends also on the use case - will it be the database with many reads or many writes? When you are talking about tasks management, you have to know how many records do you expect, and if you expect more INSERTs or more SELECTs, etc.
Regarding SQL databases, interresting benchmark can be found here:
https://www.sqlite.org/speed.html
The benchmark shows that SQLite can be in many cases very fast, but in some cases also uneffective. (unfortunately the benchmark is not the newest, but still may be helpful)
SQLite is also good in the way it is just a single file on your disk that contains whole database and you can access the database using SQL language.
Very long and exhausting benchmark of the No-SQL can be found i.e. here:
http://www.datastax.com/wp-content/themes/datastax-2014-08/files/NoSQL_Benchmarks_EndPoint.pdf
It is also good to know the database engines, i.e. when using MySQL, choose carefully between MyISAM and InnoDB (nice answer is here What's the difference between MyISAM and InnoDB?).
If you just want to optimize performance, you can think of optimizing using hardware resources (if you read a lot from the DB and you do not have that many writes, you can cache the database (innodb_cache_size) - if you have enough RAM, you can read whole database from RAM.
So the long story short - if you are choosing engine for a very simple and small database, SQLite might be the minimalistic approach you want to use. If you want to build something larger, first be clear about your needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
As .NET developers currently we're using RavenDb as our default choice of database, in the nosql scenario. Now that Microsoft introduced DocumentDb, a nosql document database-as-a-service, we're looking for the differences between the two. Database-as-a-service does seems nice, as we run RavenDb on our own server.
Ayende Rahien as an interesting post, but it's a little outdated as it compares with an old DocumentDb version. Nevertheless it's still a good read.
Edit: After reading Thoughts on Azure DocumentDB I started doubting about the pricing of DocumentDb. Let's say my data model consists of 7 collections, this means I would have to pay 7 * $25 = $175 per month! I must be making some kind of mistake here, right!?
Edit2: The idea of the creators of DocumentDb seems to put more than one type of document into a single collection, which seems a bit odd to me after using ravendb for a while now. The term collection caused some trouble understanding DocumentDb pricing as it is something completely different in DocumentDb then in RavenDb
In which scenario would you choose DocumentDb over RavenDb?
The post recommends that you put a lot more stuff in a single collection than you would otherwise. I'm not sure of the wisdom of that long term, but they propose it as a way to keep costs down. Also, since there is no cross-collection transactional isolation, it might be better if you need to update more than one document at a time, to keep them in the same collection anyway.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Why don't any of the major RDBMS systems like MySQL, SQL Server, Oracle, etc. have good full text indexing support?
I realize that most databases support full text indexes to some degree, but that they are usually slower, and with a smaller feature set. It seems that every time you want a really good full text index, you have to go outside the database and use something like Lucene/Solr or Sphinx.
Why isn't the technology in these full text search engines completely integrated into the database engine? There's lot of problems with keeping the data in another system such as Lucence, including keeping the data up to date, and the inability to join the results with other tables. Is there a specific technological reason why these two technologies can't be integrated?
RDBMS indexed serve a different purpose. They are there to offer the engine a way to optimize access to the data, both by the user and by the engine itself (to resolve joins, check foreign keys, etc...). As such they are really not a functional data structure.
Tools like full-text search, tag clouds may be very useful for enhancing the user experience. These serve only the user and applications. They are functional, and require real data structures... secondary tables or derived fields... with, typically, a whole lot of triggers and code to keep these updated.
And IMHO... there are many ways to implement these technologies. RDBMS producers would have to maybe choose some tech over another... for reasons that have nothing to do with the RDBMS engine itself. That does not really seem their job.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Say your data is fairly relational in nature, but the scale of your application has outgrown the performance ability of your database... Given that most NoSQL solutions out there seem to promise much better performance (I'm working on a real-time content recommendation engine), I'm looking at alternatives. I can think of ways to smack my data model around so it could be represented as documents, graphs, or even simple/abusive key-value pairs...
But where is the [complexity vs performance] trade-off worth while/smart?? Does it sound reasonable to increase the complexity of the application so that we can use a document-oriented database in the hopes that performance will increase?
What are some proven principles/rules of thumb to guide the design decisions in such a situation?
I would recommend Fighting the NoSQL mindset and NoNoSQL
Neither of these are biased towards traditional RDBMS despite their titles, they both give pretty decent perspectives on the tradeoffs. This topic has raged for years all over the internet but quality articles are hard to pick out of the noise. Good luck!
edit: almost forgot NoSQL data modeling techniques
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I mean: link text
why should one use this over MySQL or something similar?
SPEED
Redis is pretty fast!, 110000
SETs/second, 81000 GETs/second in an
entry level Linux box. Check the
benchmarks.
Most important is speed. No way you can get these numbers using SQL.
COMMANDS
It is possible to think at Redis as a
data structures server, it is not just another key-value DB, see all the
commands supported by Redis to
get the first feeling
Sometimes people call Redis Memcached on steroids
Like many NoSQL databases, one would use Redis if it fits your needs. It does not directly compete with RDBMS solutions like MySQL, PostgreSQL, etc. One may need to use multiple NoSQL solutions in order to replace the functionality of a RDBMS. I personally do not consider Redis to be a primary data store - only something to be used for speciality cases like caching, queuing, etc. Document databases like MongoDB or CouchDB may work as a primary data store and be able to replace RDBMSs, but there are certainly projects where a RDBMS would work better than a document database.
This Wikipedia article on NoSQL will explain.
These data stores may not require fixed table schemas, and usually avoid join operations and typically scale horizontally.