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

Facebook's Top Open Data Problems

research.facebook.com

Post reply on HN
Print view View original

31–40 of 65 posts

Re: Facebook's Top Open Data Problems

#31

Post by crazypyro »

crazypyro wrote: post #23

This is slightly off topic, but has any experienced an increase in "fake" toasts from facebook mobile? It seems if I haven't used facebook mobile in a few days or I don't respond to their toasts about very minor people in my life uploading a photo, I tend to start getting toasts that say "You have 5 notifications, 3 pokes and 2 messages.", then I open the app and it takes me to an unknown error page. Am I being too c…

If anyone cares, I went and looked at their metrics and it seems that Q2 to Q3 was one of their biggest increases in mobile alone(albeit not by a whole lot) in quite a while, yet if you look at the raw user metrics over all platforms, it was slower than almost every other quarter in terms of users gained. I'm not sure if this adds any credibility to my wild theory, but it does at least show there is something affecting the increase in mobile usage, although that could just be market factors.

Interestingly, Twitter's metrics don't appear to show any similar rise in the rate of adoption.

Re: Facebook's Top Open Data Problems

#32

Post by otterley »

seiji wrote: post #19
Goranek wrote: post #16

Earlier quoted context omitted.

Simple scales better than complex. What they need is key->value caching and for that memcached is a perfect match. I'm not saying that Redis is bad, but when all you need is key-value memory caching, redis isn't needed.

when all you need is key-value memory caching, redis isn't needed. Balderdash. memcached is actively hostile to modern infrastructure and it's not being actively developed except for routine maintenance. The first time someone stores an entire data structure in a memcache key is the moment you've lost. Playing "read blob, deserialize, update, serialize, write blob" is just dumb when you can avoid it. Other moments of…

> it's not being actively developed except for routine maintenance

Why gild the lily?

> needing to implement client-side or proxy-based replication

It's best practice to replicate the persistent store for availability, not the cache.

Almost all your other concerns appear to arise out of fundamental misuse. It's a cache, not a panacea to cover up basic design flaws in a primary data store.

Re: Facebook's Top Open Data Problems

#33

Post by yuliyp »

Cakez0r wrote: post #28
alexgartrell wrote: post #27

Earlier quoted context omitted.

That's what TAO (mentioned in the article) is for

Yes, I've read the TAO paper and referenced it heavily for my project. I'm curious about the implementation specifics of the caching layer. EDIT: More specifically, how do you efficiently cache your data such that an assoc_range query can be answered from cached without O(n) operations on your application servers. Memcached can't answer a query like "give me 50 items starting from position 0 in the list" as far as i'…

TAO is used in place of memcached. You don't ask TAO for a whole list and place it into memcached. You ask TAO for "give me 50 items starting from position 0 in the list", and the TAO cache keeps this list in sorted order.

Re: Facebook's Top Open Data Problems

#34

Post by andrewchoi »

crazypyro wrote: post #23

This is slightly off topic, but has any experienced an increase in "fake" toasts from facebook mobile? It seems if I haven't used facebook mobile in a few days or I don't respond to their toasts about very minor people in my life uploading a photo, I tend to start getting toasts that say "You have 5 notifications, 3 pokes and 2 messages.", then I open the app and it takes me to an unknown error page. Am I being too c…

Sorry if this is a silly question, but what are "toasts"?

Re: Facebook's Top Open Data Problems

#35

Post by maxerickson »

andrewchoi wrote: post #34
crazypyro wrote: post #23

This is slightly off topic, but has any experienced an increase in "fake" toasts from facebook mobile? It seems if I haven't used facebook mobile in a few days or I don't respond to their toasts about very minor people in my life uploading a photo, I tend to start getting toasts that say "You have 5 notifications, 3 pokes and 2 messages.", then I open the app and it takes me to an unknown error page. Am I being too c…

Sorry if this is a silly question, but what are "toasts"?

A type of notification:

http://developer.android.com/guide/topics/ui/notifiers/toast...

Re: Facebook's Top Open Data Problems

#36

Post by andrewchoi »

maxerickson wrote: post #35
andrewchoi wrote: post #34

Earlier quoted context omitted.

Sorry if this is a silly question, but what are "toasts"?

A type of notification: http://developer.android.com/guide/topics/ui/notifiers/toast...

Thank you! I never knew what those were called.

Re: Facebook's Top Open Data Problems

#37

Post by Cakez0r »

yuliyp wrote: post #33
Cakez0r wrote: post #28

Earlier quoted context omitted.

Yes, I've read the TAO paper and referenced it heavily for my project. I'm curious about the implementation specifics of the caching layer. EDIT: More specifically, how do you efficiently cache your data such that an assoc_range query can be answered from cached without O(n) operations on your application servers. Memcached can't answer a query like "give me 50 items starting from position 0 in the list" as far as i'…

TAO is used in place of memcached. You don't ask TAO for a whole list and place it into memcached. You ask TAO for "give me 50 items starting from position 0 in the list", and the TAO cache keeps this list in sorted order.

Yes, that's the mechanism I'm wondering about. Let's say I have:

    Application -> TAO -> Cache -> Database
I have a photo node (P1) and 125 comments nodes [C1, C2, ..., Cn] attached to P1 by the edges [(P1,C1), (P1,C2), ..., (P1,Cn)]. I'll ignore the fact that there can be different edge types for simplicity.

Lets say my page size is 50 and I want to view 3 pages of comments for the photo from my application. My application makes the following TAO queries:

    assoc_range(P1, 0, 50)
    assoc_range(P1, 50, 50)
    assoc_range(P1, 100, 50)
My question is, assuming all the necessary data cached such that all of those queries will be a cache hit, how are those edges stored and retrieved from memcached? How are the keys named in memcached?

A naive implementation might be to store the list of all edges for P1 with a key of "P1". To answer te above 3 queries, TAO then needs to pull "P1" (all 125 edges) from memcached 3 times to answer each of those 3 queries and slice the edge list up on the TAO application server... Not great, but probably an improvement over hitting the DB for it (up to a certain list length at least).

A less naive implementation might be to store the edges in buckets of 50, such that the 125 edges are stored with keys of "P1_0_50", "P1_51_100", "P1_101_150", but then time ordering comes in to play...

If my application now wants the 50 most recent items, we could store the edge lists by created date descending and I can retrieve "P1_0_50" from the cache and guarantee I have the 50 most recent items. However, lets say 10 new comments are posted... Now I need to update all my cache pages to ensure the ordering is correct, which is horrendously ineffecient!

To fix this issue, edge lists could be stored in created date ascending order instead, but then how do I know which cache page to fetch to retrieve the 50 most recent comments (seeing as "P1_0_50" is now the oldest 50 items)?

I hope that makes sense!

Re: Facebook's Top Open Data Problems

#38

Post by FLUX-YOU »

alkonaut wrote: post #20
beagle3 wrote: post #2

Something does not add up about hive: They say it has 300 PB, and it generates 4PB per day - which means, at this rate, all data was generated within the last 75 days.

Also 800.000 tables? Surely not in the sense I'm used to, that is, normalized forms where a table corresponds roughy to some business object/noun? Does table mean something else or are there 800k different types of data in there?

Yeah that's hard to wrap my head around. We have 2k in a large app and that's daunting. Really curious why that came to be (though that's probably the least interesting thing in this article)

Re: Facebook's Top Open Data Problems

#39

Post by nbm »

mandeepj wrote: post #8

Can any body throw some light on how facebook's database is designed? I am sure it will be an interesting read. I was reading somewhere sometime back that each user at fb has its own database. I think that is not possible. edit: I am googling now again on this topic. First link found is http://www.quora.com/What-is-Facebooks-database-schema

There isn't one database, although there are a few major types.

The majority of core information (attributes of people and places and pages and so forth, as well as posts and comments) is stored in MySQL and queried through TAO.

Some data is primary stored in things like HBase, such as messages.

Non-primary-storage data (indexes and so forth) exist in various forms optimised for different workloads - so data in either MySQL or HBase might also exist in Hive for data warehouse queries, or in Unicorn for really fast search-style queries.

Other data (such as logs) might reside in one or more of the various data stores, such as Scuba, Hive, HBase, and accessible via Presto, for example.

TAO: https://www.facebook.com/publications/507347362668177/

Unicorn: https://www.facebook.com/publications/219621248185635

Hive: https://www.facebook.com/publications/374595109278618/

Scuba: https://www.facebook.com/publications/148418812023978/

Presto: http://facebook.github.io/presto/

Re: Facebook's Top Open Data Problems

#40

Post by nbm »

Cakez0r wrote: post #37
yuliyp wrote: post #33

Earlier quoted context omitted.

TAO is used in place of memcached. You don't ask TAO for a whole list and place it into memcached. You ask TAO for "give me 50 items starting from position 0 in the list", and the TAO cache keeps this list in sorted order.

Yes, that's the mechanism I'm wondering about. Let's say I have: Application -> TAO -> Cache -> Database I have a photo node (P1) and 125 comments nodes [C1, C2, ..., Cn] attached to P1 by the edges [(P1,C1), (P1,C2), ..., (P1,Cn)]. I'll ignore the fact that there can be different edge types for simplicity. Lets say my page size is 50 and I want to view 3 pages of comments for the photo from my application. My applic…

There is no memcache - there is just TAO, and it talks to the database. TAO is a read/write-through cache, so the only way the data changes in the database is through TAO. TAO contains the indices necessary to answer queries like that efficiently (although there may be other systems for doing similar but more specialized or slightly different queries), as well as a cache of the data.

So, when you add a comment, TAO updates its internal structures with the new comment in the right place (after the DB is updated), and there are no "keys" that need to be updated beyond that.

Post reply on HN