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

Cache is the new RAM

blog.memsql.com

Post reply on HN
Print view View original

91–97 of 97 posts

Re: Cache is the new RAM

#91

Post by dang »

throwmastr wrote: post #89
throwaway981 wrote: post #60

Earlier quoted context omitted.

There seems to be a culture clash on HN. On one side there is California, where "dick wagging" is an unnecessary instance of gendered language, certain to drive women out of the tech industry. On the other side there's the rest of the world, where being offended by "dick wagging" seems dazzlingly childish. It's just a penis, most grown men and women know what they are and observe their motions on a daily basis. In Bh…

So now we have learn what to say and what not to say from feminists ? If you take offense at every single fucking thing that's your problem. Want Women in tech, say this and that. I won't. No one with descent background is explicitly trying to keep women from entering tech. In fact, if you are deep in tech no one has time to even make deliberate efforts that. STOP thought policing. Look , this is free country. While…

This is one of those situations where it's impossible to point out the problem in the thread without adding to it. In the future, please email us at hn@ycombinator.com instead; it will get to us sooner and more reliably anyhow.

I've detached this subthread and marked it off-topic.

Re: Cache is the new RAM

#92

Post by icelancer »

cpncrunch wrote: post #90
icelancer wrote: post #30

Earlier quoted context omitted.

I have a LOT fewer requests than you, but this one is just so irritating: >- Fucking SQL. I don't want to learn your stupid DSL. I want to give coworkers a SQL client a say "go! You already know how to use this!". If I want a new feature, then dammit, build on top of SQL the way PostgreSQL has. Odds are, regardless if its some JSON API or SQL, my language will have a client for it that will be superior than writing r…

That's an amusing (and incorrect) assumption that the smartest people are making >$150k.

That's also not the intent of the sentence, but thanks for putting words in my mouth.

Re: Cache is the new RAM

#93

Post by cpncrunch »

icelancer wrote: post #92
cpncrunch wrote: post #90

Earlier quoted context omitted.

That's an amusing (and incorrect) assumption that the smartest people are making >$150k.

That's also not the intent of the sentence, but thanks for putting words in my mouth.

Fair enough. What was the intent? That's certainly what it sounded like.

Re: Cache is the new RAM

#94

Post by jbergens »

toomim wrote: post #37
jandrewrogers wrote: post #13

A couple points I would make with respect to the article: - In-memory databases offer few advantages over a disk-backed database with a properly designed I/O scheduler. In-memory databases are generally only faster if the disk-backed database uses mmap() for cache replacement or similarly terrible I/O scheduling. The big advantage of in-memory databases is that you avoid the enormously complicated implementation task…

Can you give some refs to make these statements more real? I'm trying to understand whether an in-memory db would be faster than postgres, for instance. What's the postgres I/O scheduler, and is it good? Are there benchmarks somewhere showing the difference? Why does the I/O scheduler make a difference for in-memory vs. disk databases? Is this a subsystem that caches the database in memory? Are you saying that, with…

I think it also depends on how you structure your database and how you use it. For some things a NOSQL design is great and most of them don't have to lock over multiple tables they might be very fast at getting structured records. They might be terrible if you try to join different records (especially if they are located on different shards) and some don't have ACID if that is a requirement. Some databases like Datomic stores information in a completely different way that may be very fast for some use cases. If you have an application or a specific use case you can try a few different databases and measure how they work. I tried a small memory database and got much better performance than SQL Server gave me while the queries were easier to write, for other things this database would not have worked at all or it might have been about as fast as a relational db. As a general rule the memory db providers seems to make the case that they are faster than normal relational databases. Take a look at VoltDb or StarCounter for example.

Re: Cache is the new RAM

#95

Post by jbergens »

kephra wrote: post #78

I once learned, in the good old mainframe times, that there are 3 sizes of databases: Small size that fit into RAM, medium size that fit on one computer, and big databases, that require a cluster of computers. The relational model, and SQL databases play their strong roles in medium size databases, but are to much overhead for a fast small database, and do not scale well for big databases. It was hoped at that time,…

That is a nice scale to think about. When I look back most systems I've been involved with are small with todays servers. Rarely more than 50 GB and that actually fits into memory. How many systems actually needs more than about 1000 GB of database data? Things like images and videos can be stored separateley anyway, I'm talking about other data together with metadata about images/videos/files.

Re: Cache is the new RAM

#96

Post by ddorian43 »

ehsanu1 wrote: post #79
jandrewrogers wrote: post #13

A couple points I would make with respect to the article: - In-memory databases offer few advantages over a disk-backed database with a properly designed I/O scheduler. In-memory databases are generally only faster if the disk-backed database uses mmap() for cache replacement or similarly terrible I/O scheduling. The big advantage of in-memory databases is that you avoid the enormously complicated implementation task…

What's so terrible about mmap()? LMDB seems to use it to great effect: http://symas.com/mdb/

lmdb is single-writter-thread

Re: Cache is the new RAM

#97

Post by hyc_symas »

ddorian43 wrote: post #96
ehsanu1 wrote: post #79

Earlier quoted context omitted.

What's so terrible about mmap()? LMDB seems to use it to great effect: http://symas.com/mdb/

lmdb is single-writter-thread

How is that in any way relevant? All ARIES write-ahead-logger systems are single-writer to their logs too. No matter what kind of BS they sell you about high concurrency with fine-grained locking, it all funnels thru that single bottleneck.

The fact is that LMDB's single-writer design is not a concurrency liability in real workloads.

http://symas.com/mdb/20141120-BuildStuff-Lightning.pdf

http://symas.com/mdb/#bench

Post reply on HN