Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis-V8

redis-v8.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Redis-V8

#61

Post by h0x91b »

Shorel wrote: post #53
h0x91b wrote: post #18

Earlier quoted context omitted.

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.

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.

Re: Redis-V8

#62

Post by andrewflnr »

Shorel wrote: post #52
kryten wrote: post #37

Earlier quoted context omitted.

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 em…

I don't think most of these apply to JavaScript nowadays.

Personally, I'm interested in the general answer.

Re: Redis-V8

#63

Post by andrewflnr »

kryten wrote: post #37
andrewflnr wrote: post #32

Earlier quoted context omitted.

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 em…

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.

Re: Redis-V8

#64

Post by andrewflnr »

h0x91b wrote: post #61
Shorel wrote: post #53

Earlier quoted context omitted.

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.

Re: Redis-V8

#65

Post by h0x91b »

andrewflnr wrote: post #64
h0x91b wrote: post #61

Earlier quoted context omitted.

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.

Re: Redis-V8

#66

Post by kryten »

andrewflnr wrote: post #63
kryten wrote: post #37

Earlier quoted context omitted.

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 em…

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 fa…

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.

Re: Redis-V8

#67

Post by andrewflnr »

h0x91b wrote: post #65
andrewflnr wrote: post #64

Earlier quoted context omitted.

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…

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.

Re: Redis-V8

#68

Post by Shorel »

h0x91b wrote: post #65
andrewflnr wrote: post #64

Earlier quoted context omitted.

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…

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.

Re: Redis-V8

#69

Post by SF_Startup »

gizzlon wrote: post #36
bru wrote: post #28

Earlier quoted context omitted.

Hi, just nipticking: you wrote > 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.…

Speaking of BLINK, Dallas based IIICTECH has been using BLINK for years. They're getting trampled by both Google & Microsoft. So mutch for having a good idea & having a far shot at owning intellectual property... like a trademark. (www.ismorethan.com)

http://www.prweb.com/releases/2013/01/prweb10367324.htm

Post reply on HN