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

HBase Deprecation at Pinterest

medium.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: HBase Deprecation at Pinterest

#41

Post by ted_dunning »

aeyes wrote: post #19
lopkeny12ko wrote: post #14

Earlier quoted context omitted.

This is my first reaction as well. How in the world do you end up with close to 10 different databases in production? And furthermore, most of which are totally proprietary? Just use Postgres...

Easy: These companies have a promotion process which require you to generate "impact" to get promoted. Using existing but boring technology which solves the problem in an efficient manner apparently doesn't show off how smart you are. This is not a snarky comment from an outsider, I very much work at such a company. It's ridiculous. Edit: But I must admit that most of this was probably developed 10 years ago when the…

HBase is coming up on twenty years old.

In 2008, scaling was really hard. And the senior engineers at that point had been badly burned by trying to scale during the 2000-2005 period.

The comment about servers of the time being less powerful than smart phones of today is spot on.

Re: HBase Deprecation at Pinterest

#42

Post by riku_iki »

eclark wrote: post #24

> Production HBase clusters typically used a primary-standby setup with six data replicas for fast disaster recovery, which, however, came at an extremely high infra cost at our scale. This is the real killer. HBase uses Hadoop for its replication. That replication does 3 copies in the same data center. If you're a company that requires online data of this scale, you probably also have several other data centers or c…

> That replication does 3 copies in the same data center.

You can set replication factor 1 if you want. You just will have high chance to lose your data forever.

Re: HBase Deprecation at Pinterest

#43

Post by eclark »

riku_iki wrote: post #42
eclark wrote: post #24

> Production HBase clusters typically used a primary-standby setup with six data replicas for fast disaster recovery, which, however, came at an extremely high infra cost at our scale. This is the real killer. HBase uses Hadoop for its replication. That replication does 3 copies in the same data center. If you're a company that requires online data of this scale, you probably also have several other data centers or c…

> That replication does 3 copies in the same data center. You can set replication factor 1 if you want. You just will have high chance to lose your data forever.

The HBase write-ahead log requires a full pipeline. It speculatively drops hadoop nodes out of the write pipeline. Because of the complexity of the WAL, I don't know anyone who has tried with less. (There are a good number of ways to run HBase with no write-ahead log)

There are people who run HBase with Reed Solomon encoding on the HFiles (the store files). That can get a replication factor below 3. I don't think that Pinterest ever ran an updated enough Hadoop for that to be available.

> You can set replication factor 1 if you want.

You can't, really. HBase will fail to open regions that have files that aren't able to be read. So setting the replication factor to 1, have a single hard drive go out and the table will forever have regions that can't be opened. The name node will have a file that's got lost blocks. HMaster will pass around the region assignment until it sticks failed to open.

Re: HBase Deprecation at Pinterest

#44

Post by cortesoft »

lopkeny12ko wrote: post #14
redwood wrote: post #8

Shocking to see a company like Pinterest has built multiple in house data stores. Talking about a maintenance burden...

This is my first reaction as well. How in the world do you end up with close to 10 different databases in production? And furthermore, most of which are totally proprietary? Just use Postgres...

They are operating at a scale where you can’t “just use Postgres”

Re: HBase Deprecation at Pinterest

#45

Post by esafak »

ram_rar wrote: post #36

For companies like Pinterest, where data storage isn't the core business, should the focus be on building in-house data warehouses or leveraging managed service providers (MSPs)? While building in-house offers control and customization, MSPs can potentially address complexity and infrastructure costs. Can someone from Pinterest comment on specific performance needs (SLOs) that influenced their choice between TiDB and…

Cost, complexity, and features like transactions and secondary index. For more see

https://static.pingcap.com/files/2023/07/19065834/BRO-Pinter...

https://medium.com/pinterest-engineering/online-data-migrati...

https://www.youtube.com/watch?v=svi5AFi2_To

Re: HBase Deprecation at Pinterest

#46

Post by lopkeny12ko »

llm_trw wrote: post #35
lopkeny12ko wrote: post #14

Earlier quoted context omitted.

This is my first reaction as well. How in the world do you end up with close to 10 different databases in production? And furthermore, most of which are totally proprietary? Just use Postgres...

>Just use Postgres Now try running Postgres on vintage hardware from the period and you quickly see why we did what we did.

You would be surprised at how far a well-tuned and optimized Postgres instance will get you.

I've worked with so many teams who chase the newest and shiniest database, deploying hundreds of nodes, and spending hundreds of man-hours staffing a sysadmin team to maintain it, only to eventually replace it with an old fashioned Postgres box. You just need an experienced DBA.

Edit to add: many claims of "Postgres doesn't work at our scale" are frankly BS, and in large part due to an inexperienced ops team. Take a look at the top post on frontpage right now, for example: https://news.ycombinator.com/item?id=40372296

Re: HBase Deprecation at Pinterest

#48

Post by llm_trw »

lopkeny12ko wrote: post #46
llm_trw wrote: post #35

Earlier quoted context omitted.

>Just use Postgres Now try running Postgres on vintage hardware from the period and you quickly see why we did what we did.

You would be surprised at how far a well-tuned and optimized Postgres instance will get you. I've worked with so many teams who chase the newest and shiniest database, deploying hundreds of nodes, and spending hundreds of man-hours staffing a sysadmin team to maintain it, only to eventually replace it with an old fashioned Postgres box. You just need an experienced DBA. Edit to add: many claims of "Postgres doesn't w…

> You would be surprised at how far a well-tuned and optimized Postgres instance will get you.

I wouldn't be because I was hired after a team of very experienced DBAs saw their databases melt when trying to run analytics queries on the production database in 2012 for a telco.

We then moved to HBase so analysts could figure out what parts of the network needed extra towers installed for peak demand with 15 second intervals. You can do this today because the database sits on a machine that is between 10 to 100 times as capable as what we had back then and the number of people using cellphones hasn't increased substantially.

Again, don't look at this technology by what you can do today, but by what you could do back then.

Re: HBase Deprecation at Pinterest

#49

Post by llm_trw »

winrid wrote: post #38
dehrmann wrote: post #33

Earlier quoted context omitted.

The SQL world calls this an "index."

No. Most NoSQL dbs support indexes and secondary indexes too. In SQL world we call this "denormalization". It's called the same thing in NoSQL, too.

It's called materialized views.
Post reply on HN