Redis-V8
redis-v8.com
redis-v8.com
> Google Chrome, the open source browser from Google.
Google Chrome is proprietary software. Chromium is 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.
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 is only partially sarcastic as there were a few RDBMS + HTML template products that mercifully died).
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.
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.
Actually that's not a bad idea ... writes it down...
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...
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.
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.
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.
Javascript strikes a nice balance between performance and high level usability.
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.
Also, keep in mind that I wrote Lua-JIT, not Lua. There's a big performance difference between them too.
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 :)
It seems like this anti-pattern gained a lot of popularity lately.
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.
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.
That'll be very very cool, since MongoDB gives up 32bit systems.
And I wish it'll support Windows.
> "... is used in Google Chrome, the open source browser from Google."
should probably say Chromium.