Redis-V8(redis-v8.com)
redis-v8.com
Redis-V8
http://redis-v8.com/
12 comments
Hey guys, i am a author, as you can see project in alpha state... Everything is working, but i need some time for translate the docs/tutorials, with my english this can take a lot of time... If some one can help me with it, i will be happy.
Hi,
just nipticking: you wrote
> Google Chrome, the open source browser from Google.
Google Chrome is proprietary software. Chromium is open source.
> Google Chrome, the open source browser from Google.
Google Chrome is proprietary software. Chromium is open source.
Yep, Chrome itself is not open source:
License: Freeware under Google Chrome Terms of Service
Chrome's WebKit & Blink layout engines and its V8 JavaScript engine are each free and open-source software, while its other components are each either open-source or proprietary. However, section 9 of Google Chrome's Terms of Service designates the whole package - Chrome itself - as proprietary freeware.
http://en.wikipedia.org/wiki/Google_Chrome
License: Freeware under Google Chrome Terms of Service
Chrome's WebKit & Blink layout engines and its V8 JavaScript engine are each free and open-source software, while its other components are each either open-source or proprietary. However, section 9 of Google Chrome's Terms of Service designates the whole package - Chrome itself - as proprietary freeware.
http://en.wikipedia.org/wiki/Google_Chrome
I coped it from https://code.google.com/p/v8/...
I just tried chrome's built-in translation of your quick start page. It was surprisingly readable :)
? -> English?
Russian, by looking at the Quick Start page: http://redis-v8.com/quick-start
Russian, if I'm not wrong.
Why would I choose to use JS in a DB? Why, oh why?
This language has more quirks then a 2012 US Republican Presidential candidate.
That's the first thing I thought.
Having spent literally the last 10 years removing stored procedures and extensions from software products to eek out a little more from the black box that is a database engine and remove all the rats nest of logic, why would I want to go and do the same all over again?
Of all the things I've learned in the last 20 years or so, you shouldn't stick any logic or programmability inside the database engine. It's hell down the line.
And don't get me started on where the programmability abstraction gets fudged in with the data resulting in executable data and all sorts of security hell.
Having spent literally the last 10 years removing stored procedures and extensions from software products to eek out a little more from the black box that is a database engine and remove all the rats nest of logic, why would I want to go and do the same all over again?
Of all the things I've learned in the last 20 years or so, you shouldn't stick any logic or programmability inside the database engine. It's hell down the line.
And don't get me started on where the programmability abstraction gets fudged in with the data resulting in executable data and all sorts of security hell.
In a key-value store like Redis, it's actually quite useful to be able to generate an atomic query that says something like "If List A contains B, return C. Otherwise check whether List D contains E, and if so, return all the keys and values of Dictionary F, but otherwise return zero."
But of course, Redis already has Lua scripting which is a nearly perfect fit for its use case. JavaScript looks terribly cluttered by comparison. Some sort of V8 integration might make sense if the goal is to make Redis even easier to use with node.js, but I don't see anything in the documentation to suggest that this is what's happening.
But of course, Redis already has Lua scripting which is a nearly perfect fit for its use case. JavaScript looks terribly cluttered by comparison. Some sort of V8 integration might make sense if the goal is to make Redis even easier to use with node.js, but I don't see anything in the documentation to suggest that this is what's happening.
Couldn't this be handled with some conditional primitives like in ARM assembly adequately?
Actually that's not a bad idea ... writes it down...
Actually that's not a bad idea ... writes it down...
Exactly what bad things happen when you put logic in the database? At my current employer, most business logic is in stored procedures.
Lots. Here you go:
1. CPU time goes up. When you need to scale up, your brick wall is a lot closer.
2. When you do need to scale up, moving it out of the database engine is very expensive and time consuming.
3. The languages are archaic, obtuse and inadequate for representing business logic and don't cover ALL concerns. How do you call a web service and do an update in a transaction for example? How do you send an email?
4. It's incredibly difficult to test as the entire thing is stateful.
5. Error handling and reporting is terrible.
6. You lose database portability. This is a big issue these days, particularly when you get whacked with major licensing model changes.
7. Versioning and deployment with the application is utterly painful.
Etc etc...
1. CPU time goes up. When you need to scale up, your brick wall is a lot closer.
2. When you do need to scale up, moving it out of the database engine is very expensive and time consuming.
3. The languages are archaic, obtuse and inadequate for representing business logic and don't cover ALL concerns. How do you call a web service and do an update in a transaction for example? How do you send an email?
4. It's incredibly difficult to test as the entire thing is stateful.
5. Error handling and reporting is terrible.
6. You lose database portability. This is a big issue these days, particularly when you get whacked with major licensing model changes.
7. Versioning and deployment with the application is utterly painful.
Etc etc...
Haha, well, we're running a small site on a huge server and we're not that into automated testing. We actually send email by inserting into a table that serves as a queue. SQL server already costs a fortune. Honestly, though, I've felt a lot of that already, but didn't really attribute it to stored procedures.
Can you explain why stored procedures are faster than code in my app? It seems like they're both run in a fairly optimized VM, but I don't know much about the details. We're using C# at work, but if I was using something like Python I would be more tempted to move things into the db for performance reasons.
Can you explain why stored procedures are faster than code in my app? It seems like they're both run in a fairly optimized VM, but I don't know much about the details. We're using C# at work, but if I was using something like Python I would be more tempted to move things into the db for performance reasons.
It depends entirely on round trips to the server and your use cases.
Generally speaking though, if you keep your result set as narrow as possible, post process aggregates in code, keep your join count low and keep you round trips per request low then c# will destroy stored procedures.
Generally speaking though, if you keep your result set as narrow as possible, post process aggregates in code, keep your join count low and keep you round trips per request low then c# will destroy stored procedures.
I don't think most of these apply to JavaScript nowadays.
Personally, I'm interested in the general answer.
So many times I've seen people picking up the pieces of a "We'll just do everything in SP's!" project architecture." Anti-pattern city. The typical answer to make it scale or maintain well is to just throw it out.
Honest question. Where should you stick your db related logic if you don't want to replicate it in every app that touches the database. Do you write some sort of middleware that sits between the apps and the database and never let any apps talk directly to the database?
Exactly that. The "middleware" as you put it can manifest itself as one of several things (vastly simplified explanations):
1. Sits in front of your data store and exposes your application's API via HTTP for example. Typical SOA/public API type architecture.
2. Sits inside your web application as a component which you talk to via your internal API. In a Ruby/Python/PHP/Java/C# setting, you would typically have a class with methods on it which correspond to API calls.
3. Ships with your application (if a desktop one for example) and serves an internal API. As above but the component ships with the desktop application.
We do 1 and 2 in our product using the same shared components (domain models).
In actual fact, it's completely hiding behind NHibernate so we don't actually ever consider the database as part of the problem that needs solving. It's purely where we put our stuff when we don't want it in memory.
1. Sits in front of your data store and exposes your application's API via HTTP for example. Typical SOA/public API type architecture.
2. Sits inside your web application as a component which you talk to via your internal API. In a Ruby/Python/PHP/Java/C# setting, you would typically have a class with methods on it which correspond to API calls.
3. Ships with your application (if a desktop one for example) and serves an internal API. As above but the component ships with the desktop application.
We do 1 and 2 in our product using the same shared components (domain models).
In actual fact, it's completely hiding behind NHibernate so we don't actually ever consider the database as part of the problem that needs solving. It's purely where we put our stuff when we don't want it in memory.
1) JS is easy, almost everyone can work with it.
2) V8 is faster than LUA 5-10 times........
3) MVC - Model and crons, i think should be in DB.
You know there is a redis fork that uses LuaJIT right? https://github.com/neomantra/redis
2) Faster than LUA-JIT? Since when?
V8 faster than Lua-JIT sounds like a really bold claim. AFAIK it is the other way around, with a factor of 3x.
Nope, in redis v8 is faster, just because i have optimised GET/SET/INCR commands, and lua use a regular connection to DB like any other client, so in my case is no need to parse/encode redis format. And i can optimise any other redis functions for v8.
And it's not possible to do the same for Luajit? Doesn't sound like a fair comparison.
I started this project because javascript is more convenient and easier to teach (everyone knows). The fact that the V8 found in 10(!) Times faster than the native commands even through pipelining, it was found out only later. And as I said, none of my friends can not use LUA to do something serious, but easy to work with javascript. Most of what I've done is independent of the language I use a different approach to scripting the database.
Now cron can do directly in the database. The results you can obtain using REST request (with gzip is very less traffic). On the javascript there is a huge amount of libraries, such as Crypto, if desired, there will be templates to insert. When I finish the beta, it will be possible to write map / reduce function on the clusters. The differences will be very much.
Now cron can do directly in the database. The results you can obtain using REST request (with gzip is very less traffic). On the javascript there is a huge amount of libraries, such as Crypto, if desired, there will be templates to insert. When I finish the beta, it will be possible to write map / reduce function on the clusters. The differences will be very much.
You presume a great deal. "Everyone knows"? I've always found Lua to be a much nicer language than JS, certainly with far fewer ways to shoot yourself in the foot. I always thought "everyone knows" that. If it wasn't for the lack of libraries, Lua would be my first choice for teaching someone programming. "Doing something serious" in Lua is mainly hindered by the aforementioned lack of libraries/platforms, compounded by lack of experience.
Personally I do not like LUA, I do not force anyone to use JS. My opinion is that JavaScript is a powerful and handy, but again, this is only my opinion.
Yes, but the easy of use of JavaScript is orthogonal to the performance claims.
Also, keep in mind that I wrote Lua-JIT, not Lua. There's a big performance difference between them too.
Also, keep in mind that I wrote Lua-JIT, not Lua. There's a big performance difference between them too.
I will perform the test on the speed of Lua-jit, but I wrote redis-v8 not for speed. The fact that the V8 was faster than Lua (regular) was a surprise for me.
Because some databases have a significant usage among web developers and web developers have a significant expertise in javascript.
Which sadly doesn't mean that they have a lot of experience in the algorithms involved when handling datasets.
Since when does every use of a database involve handling datasets in a way that needs experience and "algorithms". A key value store can be used as... a key value store if need be. It doesn't need to be crazy science.
Once you start scripting your K/V store, its not a simple K/V store anymore.
I am not against databases with scripting capabilities and I do not think javascript/front end developers are per se naive, but I've far to often seen the naive assumption that just because its javascript, everyone can handle it.
I am not against databases with scripting capabilities and I do not think javascript/front end developers are per se naive, but I've far to often seen the naive assumption that just because its javascript, everyone can handle it.
This isn't true. Once you have tens of thousands of records, a poorly written algorithm or data structure is going to lead to O(n^2) behavior. That hurts. Even small sites can hit this amount of database records with ease.
So if database developers have significant experience in SQL, they should author websites using templating engines that generate HTML using SQL?
(This is only partially sarcastic as there were a few RDBMS + HTML template products that mercifully died).
(This is only partially sarcastic as there were a few RDBMS + HTML template products that mercifully died).
The docs look Russian and the Author page is Lipsum :P http://redis-v8.com/author/
Looks like a very early post :)
It sounds like he used V8 to replace redis's network stack? Doesn't make much sense to me, but maybe someone can explain why this is awesome :)
Looks like a very early post :)
It sounds like he used V8 to replace redis's network stack? Doesn't make much sense to me, but maybe someone can explain why this is awesome :)
http://redis-v8.com/norobots.txt , i have not finished a website... This awesome because of speed, easy usage, traffic less, currently a make a fully REST service with gzip...
Stop it with the smileys.
Is probably unrelated, but why do people use non-monospaced fonts in code examples on their webpage? (in this case Arial, Helvetica, sans-serif)
It seems like this anti-pattern gained a lot of popularity lately.
It seems like this anti-pattern gained a lot of popularity lately.
What's wrong with Lua when the task at hand is writing small scripts mostly putting together a few Redis primitives?
Because the tendency of most new developers is to learn one language and attempt to use it in all cases, even if it is not an optimal application.
I used to see this pattern in VB and later .NET developers, where even when another language or platform would make a task easier or more efficient, they would attempt to hammer out something workable in the one tool they knew, and actively refused (or campaigned) against alternatives.
JavaScript is the new VB.
I used to see this pattern in VB and later .NET developers, where even when another language or platform would make a task easier or more efficient, they would attempt to hammer out something workable in the one tool they knew, and actively refused (or campaigned) against alternatives.
JavaScript is the new VB.
I love JS =), and no one from my employers know LUA...
This was submitted way too early (some of the pages are still "lorem ipsum" placeholders), but it's still cool. Looks like the author is basically using V8 to script Redis, similar to how Lua can be used [1] to script it already.
[1]: http://redis.io/commands#scripting
[1]: http://redis.io/commands#scripting
Yep, you are absolutely right. Every one can do that, no needs to be a genius NoSQL programmer or something =), if you want to migrate from SQL solutions, i think redis-v8 can help.
Well I'll inform the author that his project got here. And I'll ask him about its purpose.
I am there.
I'm intrigue, how does it deal with V8 settings? js-flags command? or a different config file?
In particular, I'm thinking of V8_MAX_SEMISPACE_SIZE setting. If you cannot change this, then redis-V8 can only store max 1.4GB of data.
In particular, I'm thinking of V8_MAX_SEMISPACE_SIZE setting. If you cannot change this, then redis-V8 can only store max 1.4GB of data.
Correct me if I'm wrong - looks like it can be used as a desktop document DB?
That'll be very very cool, since MongoDB gives up 32bit systems.
And I wish it'll support Windows.
That'll be very very cool, since MongoDB gives up 32bit systems.
And I wish it'll support Windows.
Submitted too early? The quickstart page is still in Cyrillic.
Nitpick, but it's not in Cyrillic, the same way your comment (and mine) is not in Latin or Roman. It's in Russian.
I can't read Cyrillic and my Russian writing recognition skills aren't very good either. The language could just as easily have been Montenegrin or Slavonic, I have no way of knowing. And yes, our comments are in Latin/Roman script.
I'd have to agree with you. There's quite a few errors on the homepage too.
> "... is used in Google Chrome, the open source browser from Google."
should probably say Chromium.
> "... is used in Google Chrome, the open source browser from Google."
should probably say Chromium.
The downloads page has just lorem ipsum.
I guess the author of redis-v8 is not the one who submitted this to HN.
Redis-v8 quick-start is now in English.
[deleted]