Redisql: the lightning fast data polyglot]

 

A foreigner is capable of making redis fully support SQL... Tough life doesn't need to be explained ~!

This article is a translation of its blog. It is not very clear in some places. please correct me ~!

Http://jaksprats.wordpress.com/2010/09/28/introducing-redisql-the-lightning-fast-polyglot/.

 

-------------------------- Lili split line ----------------------------

 

For about a year, I have been using
Nosql datastore redis,
In various web-serving environments, as a very fast backend to store and
Retrieve key-value data and data that best fits in lists, sets, and
Hash-tables. In addition to redis, my backend also employed MySQL, because some
Data fits much better in a relational table. Getting certain types of data
Fit into redis Data Objects wocould have added to the complexity of the system
And in some cases: it's simply not doable. But, I hated having 2 data-stores,
Especially when one (MySQL) is fundamentally slower, this created a misbalance
In how my code was too Ted. The MySQL callcan take orders of magntasks
Longer to execute, which is exacerbated when traffic surges. So I wrote redisql which
Is an extension of redis that also supports a large subset of SQL. The idea was
To have a single roof to house both relational data and redis data and both
Types of data wowould exhibit similar lookup/Insert latencies under similar
Concurrency levels, I. e. A balanced backend.

I have been using the nosql database redis for about a year. In various web service environments, it is a very fast backend storage, you can also use a suitable list, set, and hash table to retrieve key-value data. In addition to redis, my backend will also adopt MySQL, because some data uses Relational Tables to make it more powerful. In some cases, it is not reliable to add the data that meets the redis data object type to a complex system. However, I hate using two types of data storage, especially when one of them (MySQL) is slow, it makes my design code very uncomfortable. When traffic surges, MySQL calls will take a lot of time to execute. So I wrote an extended version for redis-redisql, which supports a large number of SQL subsets. At that time, the idea was to develop something that had both relational data and redis data. The two types of data had similar query and write latency at a similar concurrency level, that is, the backend of a crab.

 

Redisql supports all redis data types and functionality (
It's an extension of redis) and it also supports SQL select/insert/update/delete
(Including joins, range-queries, multiple indices, etc ...) -> Lots of SQL,
Short of stuff like nested joins and datawarehousing functionality (e.g.
Foreign key constraints). So using a redisql Library (in your environment's native language), you can either call redis
Operations on redis data objects or SQL operations on Relational Tables, its
All in one server accessed from one library. redisql morph commands convert
Relational Tables (including Range Query and join results) into sets of redis
Data Objects. They can also convert the results of redis commands on redis data
Objects into Relational Tables. denormalization from relation tables to sets of redis hash-tables is possible, as is normalization from
Sets of redis hash-tables (or sets of redis keys) into Relational Tables. Data
Can be reordered and shuffled into the data structure (relational table, list,
Set, hash-table, or ordered-set) that best fits your use cases, and
Archiving of redis data objects into Relational Tables is made possible.

Redisql supports all redis data types and functions (because it is an extension of redis) and also supports SQL statements
Select/insert/update/delete (including connection, range query, multi-index, etc.), a large number of SQL statements, and some nested connections and data warehouse functions (such as foreign key constraints ). Therefore, when using the redisql database (in your language environment), you can call redis to operate redis data objects or relational data tables, all of this only uses a single service to access a single database. The redisql deformation command converts a relational data table (including the range query and connection results) to a redis data object set. In addition, the results of data objects such as redis can be converted into Relational Tables. From the current standard conversion from the redis hash table set (or redis key set) to the relational table, the transformation method from the relational table to the redis hash table is also reliable. Data can be re-ordered in the most suitable case and inserted into the data structure (relational table, list, set, hash table, or full sequence set, it is feasible to archive redis data objects into the relational table.

 

Not only is all the data under a single
Data roof in redisql, but the lookup/Insert speeds are uniform, you can predict
The speed of a set, an insert, an lpop, a select range
Query... So application code runs w/o kinks (no unexpected bizarro waits due
MySQL table locks-> that lock up an Apache thread-> that decrease
Performance of a single machine-> which creates an imbalance in
Cluster ).

Redisql not only puts various types of data in the same container, but also provides a unified query and write speed. You can estimate the query speed of set, insert, lpop, and select ...... Therefore, the application code can run as expected (no unexpected wait for MySQL lock table-> lock Apache thread-> Single-host performance reduction-> cluster imbalance ).

 

Uniform Data Access patterns
Front-end and back-end can fundamentally change how application code behaves.
On a 3.0 GHz CPU core, redis set/get run at 110 K/s and
Redisql insert/select Run at 95 K/s, both W/sub millisecond mean-latencies, so all
Of a sudden the application server can fetch data from the datastore w/truly
Minimal delay. the oh-so-common bottleneck: "I/O between app-server and
Datastore "is cut to a bare minimum, which can even push the bottleneck back
Into the app-servers, and that's great news as app-servers are dead simple
(E.g. Add Server) to scale horizontally. redisql is an event-driven
Non-blocking asynchronous-I/O in-memory database, which I have dubbedEvented Relational Database, For brespon's sake.

Only by unifying the data access mode between the frontend and backend can these problems of application code be fundamentally changed. On a 0.11 million GHz CPU, redis can achieve set/get of 95 thousand times per second, while redisql can achieve insert/select of times, the latency of the two sub-milliseconds means that the Application Service can get data from the database with the real minimum time consumption. The common bottleneck "I/O between application services and data storage" is minimized, and even the bottleneck can be pushed back to the application, you can achieve scalability by using simple methods (such as adding servers), which is too sharp. Redisql is an event-driven non-blocking asynchronous I/O memory database. To make it simple, I call it an event-triggered relational database.

 

During the development of redisql, it
Became evident that optimizing the number of bytes a row occupied was an incredibly
Important metric, as redisql is an in-memory database (W/disk persistence
Snapshotting). Unlike redis, redisql can function if you go into swap space,
But this shoshould be done w/extreme care. redisql has lots of memory optimisations, it has been written from
Ground up to allow you to put as much data as is possible into your machine's
Ram. relational table per-row overhead is minimal and text columns are stored
In compressed form, when possible (using algorithms w/negligible performance
Hits). Analogous to providing predictable request latencies at high concurrency
Levels, redisql gives predictable memory usage overhead for data storage and
Provides detailed per-table, per-index memory usage via the SQL DESC command,
As well as per row memory usage via the "Insert... Return size "command. The predictability of redisql, which
Translates into tweakability for the seasoned programmer, changes
Traditional programming landscape where the datastore is slower than
App-server.

With the development of redisql, as a memory database (writing disk snapshots for persistence), optimizing the occupied bytes is obviously becoming a very important indicator. Unlike redis, redisql has many functions. If you enter the swap space, you must be very careful. Redisql uses a large amount of memory optimization technology, which allows you to write as much data as possible into the machine memory. Each row of a relational table has the minimum overhead. If possible, text columns are compressed and stored. Just like providing predictable request latency in high concurrency, redisql also provides predictable data storage usage in memory and details for each table, the memory usage of each index when using the SQL DESC command and the insert ...... Return size "indicates the memory usage of each line. The predictability of redisql makes traditional programmers escape from the magic of data storage slower than application services.

 

Redisql is wrongly Ted to handle the c10k problem, so it is world class in terms
Networking speed and all of redisql's data is in Ram, so there are no hard disk
Seeks to engineer around, you get all your data in a Predictably fast manner
And you can pack a lot of data into RAM as redisql aggressively minimizes
Memory usage and redisql combines SQL and nosql under one roof, unifying them
W/commands to morph data betwixt them .... The sum of these parts, when
Integrated correctly w/a fast app-server architecture is unbeatable as
Dynamic Web page serving platform with low latency at high concurrency.

Redisql is designed to solve the c10k problem, so its public network speed is reliable and data is in the memory, so that you can put the hard disk into the cold room, you can get the data as quickly as estimated, in addition, a lot of data can be inserted through low memory usage. Besides, redisql puts SQL and nosql in the same container and uses a unified set of commands in them.

 

The goal of redisql is to be the complete
Datastore solution for applications that require the fastest data
Lookups/inserts possible. pairing redisql w/An Event Driven language like node. JS, Ruby
Eventmachine, or twisted python, shocould
Yield a dynamic web page serving platform capable of unheard of low latency
High concurrency, which when converted red W/intelligent Client Side programming,
Cocould process user events in the browser quickly enough to finally realize
Browser as an applications platform.

Redisql aims to provide a complete data storage solution for applications so that they can query and write at the fastest speed. Use event-driven languages that match redisql, such as node. JS, Ruby eventmachine, and twisted Python should be able to develop a low-latency and high-concurrency dynamic website service platform that was neither pushed in 500 nor in 500 (Fengjie-Translator's note. When combined with a smart client, it can quickly handle user events in the browser, and finally use the browser as the application platform.

 

Redisql: The polyglot that speaks SQL and redis, was
Written to beEvented Relational Database,
Missing piece in the 100% Event Driven Architecture spanning from browser
App-server to database-server and back.

Redisql: as an event-triggered relational database, it should be said that it supports multi-language SQL and redis. The missing part will jump to the browser and then to the application server in the 100% event-driven architecture, go to the database server, and then return? -- Translator's note ).