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 9 years ago.
Improve this question
SQL is one of the most powerful and most currently used languages​​, but for purposes of curiosity and learning would test new technologies and want to know what are the fastest.
I text talking about NoSQL (json) and also about "plain text" file (. Txt or. Dat or. INI) with information from publications, settings, and the like.
What is the fastest processing, taking for example the Wordpress CMS is a very famous and one of the largest in the world, it uses SQL, say we make a request of 50 posts from the database, using the default template, all standardized compared with a requisition 50 posts from the same hierarchy but in file. txt or json file, which technology and fashion that renders faster?
If you will work with storage only in read or write, json or text file will be more faster than mysql, otherwise if you want to process complex data, mysql is faster.
If you want to work with less overhead, try to use SQLite database or similar
NoSQL databases like Redis, MongoDB is faster than MySql, but for using it, you must have personal hosting with root access
Although I don't have numbers to prove my guess, I think that any database will always be faster than a text file, just consider its indexing capabilities.
If instead you want to compare different databases, then, as others already said, it's a matter of the specific domain / problem you're working on and the structure you gave to the specific database schema.
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
If I wanted to run a small personal site that added, say, 2000 rows of data (150 kb) every hour, would there be any significant difference between using a CSV file or SQL database? I am very new to databases and currently have a prototype that appends data to a CSV file for simplicity, but I would like to know if there are any downsides in speed or memory. I will only need write and lookup. Also, if there is a large amount of redundant data, will a relational database be able to store or detect this efficiently? I do not fully understand the concept.
Edit: this question is not a duplicate of my other question. The other concerns an interchange format that should work between a server and a website, while this question is about a method to store data as a flat file or database.
A CSV is a sequential text file, so lookups will be O(n). That is, it wil take 10x longer to lookup in a file with 10,000 lines than one with 1000.
For this reason, id recommend a SQL database, as they have built in indexing features. You can use something like Access or SQLlite for next to nothing.
The only real downside to a SQL database is that you have to learn how to use it.
So, sql has several features that you need to imlement when using CSV.
CSV won't let you create indexes for fast searching.
If you always need all data from a single table (like for application settings), CSV is faster, otherwise not.
What are some disadvantages?
No indexing
Cannot be partitioned
No transactions
Cannot have NULL values
As per your case as you have large data....its better to go with database rather than using csv.
You can create constraints like unique key constraints to uniquely identify data....There are several features that trival CSV flat file will not support.
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 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.
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
In my app I use a static database to store all counties and census areas with the states and territories of the US. This gets updated by the government every 10 years. I use it to search within a county but there are multiple counties of the same name so a state or territory has to be picked first then they select the county within. My question is that I currently have that data in an SQLite database, is that the most efficient or should I use core data? Ther are 3600 lines with 4 items on each line. I just want it to be the most efficient way of storing and reading the data. There will be no writing to it. So which should I choose, I'm open to others than the two I mentioned.
for you case:
core data:
more flexible
(+) it's a ORM (a big plus! So you can add methods to your data models or store whole object-trees with one command)
(+) better integrated into XCode
(+) can easy handle migration of the data scheme
(-) performance (in your case, 3600records only one table)
sqlite:
(+)performance
(-)only C bindings (or you need a
framework)
and don't forget, CoreData is another layer on the top of sqlite. So,.. it's not so easy to compare those both things.
Core data is not a database, it's an object model graph, based upon a database which may (or not) be SQLite.
Using CoreData would need to rebuild all your queries in your app. You're using a rather small and static database, which, I guess, is working fine. Why do you want to change ? Does your app experiencing some speed problems (in that case set up an index on your columns)? Whatever your choice may be, I bet you won't notice any improvement from a database to another with such a simple and small database.
You can look at this answer about CoreData.
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.