I am pretty new to NoSQL and would like to fully understand the concept of namespace and how it compares to SQL schema.
I have seen plenty of useful analogies between tables, row, ... and their NoSQL counterparts.
Could you please help me understand the namespaces ?
In particular, I would like to know how I could leverage them to segregate the data of my dozen of customers ? I want to prevent accidental information leak between two of then, while still using a single database.
It really depends of the database engine you are using, it is hard to give a generic answer.
Ideally, if you really want to segregate the data, you can use multiple databases (in Redis, Redis Enterprise, MongoDB). In this case you are sure that data are separated. But you say you want to use a single DB. (why?)
If you want to stick with a single database you have various options, once again depending of the database engine you are using.
If you are using Redis:
you can use specific namespace based on key pattern, for example app:cust-001:orders, and you control the access to the data based on the key name/pattern. In Redis 6.0, the notion of ACL (Access Control List) has been added allowing you to limit the operations/access to the data based on a key pattern, for the connected user. This will allow you to have a good control of the data and who can see/manipulate them
If you are using MongoDB:
you can use multiple collections (tables), for example, prefixing the collection name with a context.
or you can use a composite key, where one of the fields will be your context
In both cases, for Redis and MongoDB, you are kind of creating using business logic the concept of "database".
If you provide more details/examples, the community can probably give you a more detailed answer.
Related
I want to store the comma separated ids on a child node & how can I filter data as in sql we can use IN clause to fetch data any possibility in firebase to perform this kind of operation in firebase database.
Please suggest any possible solution for this.
Firebase Realtime Database doesn't have the equivalent of SQLs IN clause. It also doesn't have a way to find a substring in a value. So the data model you are looking to use, doesn't allow the use-case you want. As usual with NoSQL databases, the solution is to pick a data model that does allow your use-case..
The most likely cause I know for the structure you describe is to associate the child node with a bunch of categories. If that is your case, read my answer here for a proper data structure: Firebase query if child of child contains a value
This is one of the cases where the new Cloud Firestore database offers better querying support, since it recently added a feature to efficiently test if an array contains a certain value (video). If you're only just getting started with your project, you might want to check if Firestore is a better fit for your use-cases.
I have been using C# to run operations on a DocumentDB instance and really like it so far. I have a lot of C# code that queries from multiple collections to create new collections from the relationships between the first two collections.
Can I essentially move my logic up to the server in stored procedures? I tried answering this question for myself, but all I could find was documentation on how to acquire the collection associated with the stored procedure. So then I thought, could I call a stored procedure that called another stored procedure, passing in the first collection?
Is there any way I can refer to multiple collections in a stored procedure somehow?
Would it be easier to find an easier way to know what belongs to each "collection" if I store everything in the same collection?
Stored procedures run inside of a single collection (or a single partition in a partitioned collection). A call to a stored procedure can only operate on the data in that collection/partition.
When I see this question asked, I usually wonder if you are thinking of collections as a direct analog to tables from the SQL world or even the use of the word "collection" from the MongoDB world. In DocumentDB it's best to not separate your data up by type but rather to mix data of different types in the same collection and separate along some other scale out boundary like tenant, user, geography, etc. If you do that, as long as your stored procedure doesn't need to cross that tenant, user, or geography boundary, it'll be able to provide you with fully ACID cross-document transactions.
i would like to ask for help with my backend flux.
I'm starting to use SQL now, and i have some background in noSQL databases, but i don't know SQL much, so i'm having some trouble finding out how to register my schemas.
I'm using node-mysql, and the way that i can create schemas is calling the method query, like:
myInstance.query( 'CREATE TABLE users (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(100) NULL NULL,
email VARCHAR(100) NULL NULL,
password VARCHAR(100) NULL NULL
)');
The problem with this solution is: this code will run in every server initialization.
So, i would like to know how to check if the schema already exists, and.. is this a good solution?? I was thinking in a bash script that creates all schemas, them i don't need this if statements.
Thanks.
What you are calling a "schema" is really a "table". Hence, create table statement, rather than create schema. This is very important. Perhaps this part of the documentation will help you understand the difference.
There are four very different constructs:
Database Server -- how you connect to one or more databases
Database Instance -- a grouping of objects, typically a unit of backup and storage
Schemas -- a grouping of objects (which may be within a database), typically a unit of permissions
Tables -- where data is stored
Note that different database systems have slightly different variations on these.
Of course, "tables" have schemas, which is why it is easy to get confused.
Generally, the management of the database is handled separately from user applications. That is, the DBA (which might also be the developer) would create the database, manage access, handle backup/recovery, and other things. The application would simply connect to the database and assume that the correct tables and data are there.
That is, under most circumstances, you wouldn't be creating tables in application code. Just use the tables that should already have been created for your database.
You can modify you sql statement to
CREATE TABLE IF NOT EXISTS users (…
That way the code will run on server init, but not do anything and also not fail when the tables are already there. See the corresponding mysql documentation.
Contrary to the answer you got, to have the SQL statements in application code is not that uncommon for backends.
I recently followed a tutorial to create a node.js server connecting to orchestrate.io database. The problem is I now want to point the server at a mongodb hosted on mongolab - currently I am declaring a variable:
var db = require('orchestrate')(APIKEY);
which allows me to retrieve data using something like:
db.get('collection', key)
.then(function(result){
console.log(result.body);
});
My question is - Is there any way I can switch the value of 'db' to point at a mongolab database without changing the structure of the get request?
I work at Orchestrate and we do not believe in data lock-in. I hope you'll reconsider using our service, but here's some advice if you choose to leave...
It sounds like your code is fairly minimal, so you may be best off recreating your Node server with another tutorial specific to Mongo.
That said, if you are using simple key-value storage, it should be as easy as rewriting the db.get Orchestrate lines to be db.find functions from MongoDB. If you've loaded a lot of data you could export it from Orchestrate, then import into Mongo (either manually, or using another tool).
If you're using some advanced, built-in Orchestrate features, such as full-text search, relation graphing, time-series data, and geographic look-ups, it may take some more effort (and MongoDB experience) to switch. If you'd like these features in a highly scalable database-as-a-service that you don't have to maintain, you know where to find us.
I know memcache and redis are used when caching needs to be there for more than one servers.
I'm creating a node application which will run on single server only and uses mysql as db, and i need to hash around 100,000 keys and each key will contain json string of 200 in length, so that i dont have to call mysql for reads.
If i use memcache or redis i will use a callback to get my data, but if i use javascript hash i can get the data synchronously, but will it affect the application somehow, like high usage of memory. Which one i should be using for a application like this?
I know memcache and redis are used when caching needs to be there for more than one servers.
Not necessarily, for instance Facebook puts a memcache instance in front of each of their mysql servers. You can use Redis/Memcache for fast computation (e.g. real-time analytics) without having a whole cluster.
and i need to hash around 100,000 keys and each key will contain json string of 200 in length, so that i dont have to call mysql for reads.
It seems like premature optimization to mee, if MySQL have enough RAM (the dataset live in memory) you don't have to worry about performance, that's just 100 keys.
If i use memcache or redis i will use a callback to get my data
If really depends on what language you use (Ruby and Python offers synchronous Redis clients) and what type of paradygm is used (event-loop, thread pool...)
but if i use javascript hash i can get the data synchronously
To be more precise, that's just because you are using node_redis and not because you are using a javascript "hash" (an object in fact).
but will it affect the application somehow, like high usage of memory
It depends if you are loading all keys in your process or not, if you are using a Redis Hash, you will be able to only query the field you want and not the whole field each time.
Which one i should be using for a application like this?
The best thing to keep in mind is to lower the number of application you have to maintain in your stack while still using the right tool for the right job. Here MySQL could be enough but if you really want to use Redis or MemCached, I would go for Redis. It will offers simirarly the same features as memcached with the same performances will allowing you to use its other data-structures in the future without needing another application in your stack.
Moreover, if you put all your data in a Redis HASH, you will be able to retrieve a field (hget) or a group of fields (hmget) or all fields (hgetall) with just one call.
Finally, regarding recent statistics and Redis ecosystem (GUI, hosting, librairies, ...), Redis seems to be way more future proof than Memcached if you really want to go that way.
Disclaimer: I am the founder of Redsmin, an online developer oriented service for administrating and monitoring Redis.
It depends- you could even opt for memcached over mysql :). For simple operation such as only -readonly just storing it within your javascript code (I believe as dictionary objects) is enough. But be sure that you have enough RAM :) .