Sign in to follow this  
moeen k

are non sql databases better than sql databases?

Recommended Posts

hi.

 

im using redis for routine used data in y game on my server. i want to know are they really faster? how much? and i think the answer is absolutely yes if as its said it is on cache not on hard disk memory there there will be no time taken t bring data on memory. so is this mean it takes place on ram of the machine that is working on?

for big data is this going to be critical for the ram that holdes many different data?

 

cant i simply use xml instead if redis or it has the same problem of reading from file on hard disk?

 

there are so many client that wrote library for working with c# like serverstack and cookSleeve. im not going to pay money for any of them right now but most of them have a free versions for little usage. which of them are best to work on for best feature and pay less?

 

thank you for help.

Share this post


Link to post
Share on other sites

As long as all your data fits the memory it hardly matters if you use SQL, non-SQL or just plain collections of objects in memory. If it doesn't fit then the fun starts and what is "better" depends on structure of your data.

 

SQL databases tend to be more "mature" as they are simply longer on the market. They may be faster if your data is spread across many tables. But nothing comes for free and if you screw something (indexes, queries, not enough hardware resources) performance will be far from acceptable.

 

Non-SQL on the other hand are great for simpler usage or for objects without strictly defined structure. They are more flexible with what you can keep - this may be good or bad thing depending what you need.

Share this post


Link to post
Share on other sites

as i read many documentations its just a key based database. so it means i only can access my value record by key name? its impossible to query like a sql database?

 

and you think as serviceStack is not free to work with, can stackExchange.redis be a good replacement for it or no?

 

as i know basically redis is a key-value database. simply in c# you have Dictionary datatype that works same way. some libraries give you some features  that help you work with class objects or structs but in the end they use inner functions to convert them to a format like json. so if i use Dictionary and dont use redis, do i lose anything?

Edited by moeen k

Share this post


Link to post
Share on other sites

Moeen, so far you hesitate to tell us what your data looks like (what is it's structure) and how big it may be (number of objects, size of each object).

 

SQL and non-SQL solve very different problems so this information will help us suggest the best solution to you.

Edited by Deflinek

Share this post


Link to post
Share on other sites



Like

Posted Today, 07:34 AM

Moeen, so far you hesitate to tell us what your data looks like (what is it's structure) and how big it may be (number of objects, size of each object).



SQL and non-SQL solve very different problems so this information will help us suggest the best solution to you.

 

well..... i want redis for fast changes in database like when data changes when player has logged in and is playing. data like he has logged in ro not. position and... after certain events or after he disconnected they data will send to sql database.

 

the problem is redis has no tables. it just has keys and values and libraries that let you work with it are not free and data type in it are so limmited(as i resaearched basically you cant send class bjects as values to it and some libraries serialize classes to some formats like json and save that way) and  c# dictionary has the same feature and accepts more datatypes like class objects. the problem is space for dictionary is limited and you cant send lots of data to it. i counted for start my data should keep data about 2000 to 4000 and 2 gigabytes of ram player row data. in a post on a forum i found that someone said class objects has their own place in memory and dictionary just will get the refrence to them so there will be no problem of space.

Share this post


Link to post
Share on other sites

It sounds like you have a sever which has some game-like behaviour, and you need to get data to respond to a user's requests at least once every few seconds. You think you want Redis because it provides a caching mechanism as well as a persistence mechanism, which isn't a bad idea. What I'm getting from you so far is that you don't know what to use as a key, and you're worried about serialization/deserialization time for the objects you're storing as values in Redis. Correct me if that's wrong.

 

 

Let's take a step back. What is the data you want to store (as in, if you were going to make one or more C# classes that represented it, what properties and private fields would these classes have)? How do you want to be able to look this data up (as in, what would go in the WHERE ... clause if you were to search for this data in an SQL database)? And how often do you expect to be making such queries (don't forget the appropriate units; this is a # of queries per second per user, usually)?

 

If you can answer those, you'll start to develop a clearer idea of what your requirements are. There's nothing wrong with Redis AFAIK, so you just need to figure out how to use it with your dataset.

Share this post


Link to post
Share on other sites

A few corrections to your misunderstanding here:

 

The reason why Redis is fast is not because it's a NoSQL Database, it's because it's an in-memory database.  If someone implemented an in-memory, scalable SQL database, it will be fast too.

 

NoSQL does not have to be a KV-driven, or document-based database as people have started to commonly refer this as.  There's also a graph database (e.g Neo4j).  It's a bucket term for any kind of database that are not using relational tables to store its data.

 

 

What is the difference between redis and C# dictionary?  Redis is a cluster of computers all dedicated to store your data in-memory, while C# dictionary only persist your data locally in one node.  If you are running your code in multiple server nodes, you can start seeing a problem where some data might exist in one node, but a request tried to retrieve it from another node.  That's what Redis is solving that it makes sure your data is available across the network.

 

You can put XML on redis since it isn't trying to format your data in anyway.  Set the key to your document to any string, and the value to be your XML.

Share this post


Link to post
Share on other sites

In the end, the question boils down to which is better, a Mercedes or a Vespa. They're different things that do different things, and you must know which thing you're going to need. If you want to go to another city 500 kilometers away, the Mercedes will be faster and more comfortable, but if you deliver pizza, you most likely want to stick with the Vespa, especially during rush hours.

 

A NoSQL database in general is a database which is just that, no SQL. It does not let you do queries like "Find our top 50 customers who live in Brazil and whose name contains "er", and sort them by the date of their last order, but capitalize their first name before outputting".  On the other hand, this lack of functionality may allow for faster implementations, under some constraints.

 

Redis, in particular, is for the most part a hash table which stores binary blobs and also has built-in functionality for saving the hash table to disk (and restoring from a save), with a small (depending on how you configure it) risk of losing transactions.

Since it never accesses the disk under normal conditions and since both the query language and the operations it offers are comparatively easy, and since it offers more relaxed consistency guarantees, it is generally faster. But that is not necessarily the case in all situations. If you configure redis to provide the same consistency guarantee as a "typical" SQL database, the difference won't be that great.

 

Also, in some situations, a SQL database (which usually uses some sort of binary tree for indices) may very well be equally fast or faster. A hash table is O(1), but the hash function isn't (and isn't a free operation), and unhealthy access patterns can have great influence. So if, for example, you end up doing operations that require a lot of lookups on similarly prefixed keys, you may very well do better with SQL (and with less implementation work).

 

Above all, you must be sure what kind of data you need to store, how much of it in what intervals, and what guarantees (and failover, and whatever) and query functionality you need. Once that is clear, the question whether A or B is faster is not really a concern any more.

Edited by samoth

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this