Redis: List all data structures - redis

I'm absolutely a newbie using redis.
I need to:
list all databases
list all data structures
I've connected to redis 4.0.11 server using redis-cli.

Redis is a key value storage not a database, You can't query or structure the Redis like you do in a database. You can only receive the relevant value from the key that you are passing.
Usually instead of database a key value storage like redis is used to to high performance key value storage and retrieve, if performance of a database is not enough.

Related

Store temp data on Express Server vs. keep using SQL

I'm creating a socket io application that has many rooms and many users inside of these rooms. I needed a way to store temp data about the room and its users. (socketio can store data about each socket connection but not the room) I thought about using a HashMap on the server (key: room) => (val: tempData) but thought that would be too much overhead for Node.JS since it's single-threaded. So, I decided to just store temp data in a Postgres table. Temp data get added and deleted often. There are a few boolean values, etc.
The essence of my question: Is it okay for me to store temp data on Postgres or would it be better to just store it in a HashMap on Express Server?
Thank you!
If you have 1 server then keep it in memory
If you have more than 1 server OR want the data to stick around if the server is restarted hold it in the DB

Redis - Cache entry evictions across multiple databases

When using multiple databases on a single redis instance and its memory is full, when I'm trying to insert new data it samples a number of keys and it applies an algorithm to them to determine which ones should be evicted.
But, if I'm using db0 and db1 and I'm trying to insert a new record into db1, will redis sample keys from the same database or does it sample them globally?
When it does eviction, Redis chooses eviction candidate from all databases.
In your case, it might evict keys from db0 or db1.

How to create own database in redis?

There are 0 to 15 databases in redis.
I want to create my own database using redis-cli.
Is there any command for it?
Redis database is not an equivalent of database names in DBMS like mysql.
It is a way to create isolation and namespacing for the keys, and only provides index based naming, not custom names like my_database.
By default, redis has 0-15 indexes for databases, you can change that number
databases NUMBER in redis.conf.
And then you use SELECT command to select the database you want to work on.
You don't create a database in Redis with a command - the number of databases is defined in the configuration file with the databases directive (the default value is 16). To switch between the databases, call SELECT.
Use select, for example:
select 1
select 2
...
I found this relevant when I encountered the same question:
Redis different selectable databases are a form of namespacing: all the databases are anyway persisted together in the same RDB / AOF file. However different databases can have keys having the same name, and there are commands available like FLUSHDB, SWAPDB or RANDOMKEY that work on specific databases.
In practical terms, Redis databases should mainly used in order to, if
needed, separate different keys belonging to the same application, and
not in order to use a single Redis instance for multiple unrelated
applications.
The bolding is my addition.
Read more here: https://redis.io/commands/select
For the question of how to select a "database", it is the same answer given here:
$ select 1
And also some useful stuff about persistence, if RDB/AOF were mentioned: https://redis.io/topics/persistence

Using redis as an LRU cache for postgres

I have postgres 9.3 db and I want to use redis to cache calls the the DB (basically like memcached). I followed these docs, which means I have basically configured redis to work as an LRU cache. But am unsure what to do next. How do I tell redis to track calls to the DB and cache their output? How can I tell it's working?
In pseudo code:
see if redis has the record by 'record_type:record_id'
if so return the result
if not then query postgres for the record_id in the record_type table
store the result in redis by 'record_type:record_id'
return the result
This might have to be a custom adapter for the query engine that you are using.

SSIS data import with resume

I need to push a large SQL table from my local instance to SQL Azure. The transfer is a simple, 'clean' upload - simply push the data into a new, empty table.
The table is extremely large (~100 million rows) and consist only of GUIDs and other simple types (no timestamp or anything).
I create an SSIS package using the Data Import / Export Wizard in SSMS. The package works great.
The problem is when the package is run over a slow or intermittent connection. If the internet connection goes down halfway through, then there is no way to 'resume' the transfer.
What is the best approach to engineering an SSIS package to upload this data, in a resumable fashion? i.e. in case of connection failure, or to allow the job to be run only between specific time windows.
Normally, in a situation like that, I'd design the package to enumerate through batches of size N (1k row, 10M rows, whatever) and log to a processing table what the last successful batch transmitted would be. However, with GUIDs you can't quite partition them out into buckets.
In this particular case, I would modify your data flow to look like Source -> Lookup -> Destination. In your lookup transformation, query the Azure side and only retrieve the keys (SELECT myGuid FROM myTable). Here, we're only going to be interested in rows that don't have a match in the lookup recordset as those are the ones pending transmission.
A full cache is going to cost about 1.5GB (100M * 16bytes) of memory assuming the Azure side was fully populated plus the associated data transfer costs. That cost will be less than truncating and re-transferring all the data but just want to make sure I called it out.
Just order by your GUID when uploading. And make sure you use the max(guid) from Azure as your starting point when recovering from a failure or restart.