Hacker Newsnew | comments | show | ask | jobs | submit | wicknicks's comments login

The fact that we can do parallel reads from an SSD does give more flexibility to DB developers.


Exactly. Q=32 Random 4k IOP reads are much, much faster than a queue depth of 1 on SSDs. On regular hard drives you might see a 200% speedup with a high queue depth, on SSDs you could see 1000-3000% speedup.


SSDs live off their internal parallelism, if you aren't using a Queue>16 you are not making real use of an SSD. Q=32 or even Q=64 are usually the right settings.

It all depends though if you want throughput or latency. If you really really care about latency you should balance the queue depth and probably use it between 16 and 32. The reason is that with higher queues you get more collisions on the same die and then latency suffers. There are read-read, write-read, erase-write and all the other combinations but those three are the interesting ones.


I'm going to provide basic answers here. You can look at the homepage for more detailed answers (the video linked there is very helpful too) [1].

Main use case: Multi-threaded low latency data access. It is optimized for use cases where the insert/update rate is very high. In short, it has an LSM tree to quickly add new/updated records. At frequent intervals this LSM tree is merged into the on-disk pages. It is very well engineered, making the lookups very fast as well.

Queries can touch data on disk as well.

Rocks is an embedded database. Natively written in C++, but has bindings for other languages. [2]

No, nodes do not talk to each other.

Something I am personally excited about: RocksDB has a merge operator, which is (probably) still in development. It allows you to update the value of an entry by providing a merge function. It is extremely useful to merge data if you binary format supports it (for example, protobufs do this natively, and it will be very smart to store your protobuf binary natively in Rocks, and do regular merges to it).

No, an in-memory dictionary will provide far fewer guarantees and features.

[1] http://rocksdb.org/

[2] https://github.com/facebook/rocksdb/wiki/Third-party-languag...


Germany with 2.8 million is equally interesting. The country's population is 80m. Atleast one in 35 people there is in the top 1%.


France has 3.5 million with an even smaller population of 66 million so one out of twenty. Even though it's not very stable from a financial perspective.


It depends on personal taste. But if I were going to a country I never visited before, there would be very little time to do anything else other than sightseeing, mingling with the locals, learning about their culture, their history, the food, and if you are anywhere near one, visit the national parks and take the safari.

Document everything you see. Take a good camera with you, and if you don't know how to use an SLR, this is the perfect time to learn some basic tricks. Once you pick a camera, you can find some tutorial on the web, which teaches you the basics for that brand/model.

I would use this time out to "take a break" from computer science. But if you can't stay away from it, pick up a book like SICP (http://mitpress.mit.edu/sicp/). This is one of those books which you want to read away from all distractions and think deeply about. If you can, download the accompanying video lectures:



5 weeks is a long time. I could spend a week or two mingling and sightseeing, but burnout will eventually set in, and I would need a small break.


I couldn't find any documentation about it, but is there any way to achieve forward/backward compatibility with Transit?


Yeah, I hope I am interpreting this the wrong the way. But instead of doing

we have to

    .orElse("UNKNOWN");  //[1]
Not sure why this is going to be better?

[1] http://www.oracle.com/technetwork/articles/java/java8-option...


That's not a fair comparison, as the flatMaps are eating nulls (really Optional.empty()s) while the naked calls will throw NPEs. The equivalent code for the first case is:

  String result = "UNKNOWN";
  T a = X.getA();
  if (a != null) {
    T b = a.getB();
    if (b != null) {
      String c = b.getC();
      if (c != null) {
        result = c;
Optional (like Scala's Option or Haskell's Maybe) are useful because they force you to reason about "empty" cases. Whereas in typical java code there is no way for the compiler to force to you handle the possibility of nulls (thus leading to NPEs), Wrapping a type in Optional forces you to deal with the case where the result is not present, leading to more correct programs. Plus, it gives you handy tools for dealing with non-present values, like allowing a chain of computation--any step of which may fail--without needing failure checks on every step.


The problem is not to to just get from point A to B, but to have a good experience doing it. Air travel is getting worse every year. Starting from the airport checks to the long immigration lines (when traveling internationally) and super expensive fares for those "cuddly" seats, it can make holidays more exhausting than work. And if you live an hour from the airport, well good luck!

My idea of a grand future is when we can travel across the globe in less than hour, and pay less than $50 doing it.


The above link is a summary to the paper. Here is the actual publication: http://cnlab.kaist.ac.kr/~ikjun/data/Course_work/CS642-Distr...


> The world is wide open to you.

In the United States probably. The author doesn't sound too old, and says that he/she got access to the internet much later. Which means the author is probably from the Middle east or China or South Asia. The work culture there is not as open as in the west. Daily job means monotonous routine work. What excited him about the prime numbers problem was the novel aspect of it, and the fact that he was in control. Later, in his/her day job, that was no longer the case -- someone else was making the decisions. Until these nuances trickle into daily jobs, most people will sooner than later burnout.


Then move. To a different city or a different country. It is a very difficult thing to do but you shouldn't be miserable for a third of your day!

Get yourself some good skills and apply to jobs you really think you want instead of whatever the local industry has to offer.


Yes, though actually moving isn't all that hard compared to all the other things you do one a daily basis.


Took me a while to figure it out too. I think the title would have been best written as "Hadoop and Go".

Its maybe because I'm new to the language, but I have to add 'lang' to all my Google searches for Go documentation/tips, otherwise the keywords are almost always misinterpreted.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact