Haters Gonna Hate (Eric Evans對NoSQL的冷靜看法)
Haters Gonna Hate
Posted March 28, 2010
If you've been around for more than a few years, you've probably bore witness to how susceptible the tech industry is to hype. Some new-shiny comes along, people lose their minds, and seemingly overnight The Next Big Thing has spread like wildfire. Like it or not you find yourself bombarded by blog posts, tweets, articles, and water cooler chat from wild-eyed co-workers. Clearly, Ted Dziuba knows what I'm talking about.
Ironically though, what Ted is missing is the corollary, the equally annoying contrarian who takes it upon himself to set the world right by refuting The Next Big Thing, usually with straw-men and a lot of hand-waving. Seriously dude, don't feed the trolls.
Because I can be a contrarian too, let's have a closer look at some of Ted's points.
The idea is that object relational databases like MySQL and PostgreSQL have lapsed their useful lifetimes, and that document-based or schemaless databases are the wave of the future. Never mind of course that MySQL was the perfect solution to everything a few years ago when Ruby on Rails was flashing in the pan. Never mind that real businesses track all of their data in SQL databases that scale just fine. (For Silicon Valley readers, Walmart is a real business, Twitter is not.)
No, the idea is not that relational databases have lapsed their useful lifetimes, and at least in the case you later cite (Cassandra), the data-model is not considered a feature when compared to relational databases. And Twitter has indicated that they aren't using Cassandra as a replacement for everything, they are still using MySQL, so maybe there's still hope that they can be a Real Business someday.
Also, just because a "real business" like Walmart can cope using a relational database doesn't disqualify any business that can't from being "real", that's just dumb. Even where it is technically possible, there are cases when the economics of running the business preclude the costs of using say Oracle.
So you've magically changed your backend from MySQL to Cassandra. Stuff will just work now, right? Well, no. Did you know that Cassandra requires a restart when you change the column family definition? Yeah, the MySQL developers actually had to think out how ALTER TABLE works, but according to Cassandra, that's a hard problem that has very little business value. Right.
I had considered trying to explain here how the differing use-cases and data-model made this less of a problem than Ted perceived it to be, but it's probably easier to just point out that it's basically fixed (see CASSANDRA-44).
I'm not just singling out Cassandra - by replacing MySQL or Postgres with a different, new data store, you have traded a well-enumerated list of limitations and warts for a newer, poorly understood list of limitations and warts, and that is a huge business risk.
I can't speak for other NoSQL projects, but I can assure you that if you have a work-load that can be reasonably accommodated by MySQL or Postgres, then that is what we will recommend you use. For those that can't, they're just going to have to live with a newer, less understood list of limitations and warts, because otherwise there is no business.
The sooner your company admits [that you are not Google], the sooner you can get down to some real work. Developing the app for Google-sized scale is a waste of your time, plus, there is no way you will get it right. Absolutely none. It's not that you're not smart enough, it's that you do not have the experience to know what problems you will see at scale.
The takeaways here I believe are, don't prematurely optimize, Google alone has the scale to justify distributed systems, and you are dumb. One out of three, not bad.
NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL. In the meantime, DBAs should not be worried, because any company that has the resources to hire a DBA is likely has decision makers who understand business reality.
Any company that has decision makers who understand reality will know to use the right tool for the right job.
Categories: cassandra nosql
Posted March 28, 2010
If you've been around for more than a few years, you've probably bore witness to how susceptible the tech industry is to hype. Some new-shiny comes along, people lose their minds, and seemingly overnight The Next Big Thing has spread like wildfire. Like it or not you find yourself bombarded by blog posts, tweets, articles, and water cooler chat from wild-eyed co-workers. Clearly, Ted Dziuba knows what I'm talking about.
Ironically though, what Ted is missing is the corollary, the equally annoying contrarian who takes it upon himself to set the world right by refuting The Next Big Thing, usually with straw-men and a lot of hand-waving. Seriously dude, don't feed the trolls.
Because I can be a contrarian too, let's have a closer look at some of Ted's points.
The idea is that object relational databases like MySQL and PostgreSQL have lapsed their useful lifetimes, and that document-based or schemaless databases are the wave of the future. Never mind of course that MySQL was the perfect solution to everything a few years ago when Ruby on Rails was flashing in the pan. Never mind that real businesses track all of their data in SQL databases that scale just fine. (For Silicon Valley readers, Walmart is a real business, Twitter is not.)
No, the idea is not that relational databases have lapsed their useful lifetimes, and at least in the case you later cite (Cassandra), the data-model is not considered a feature when compared to relational databases. And Twitter has indicated that they aren't using Cassandra as a replacement for everything, they are still using MySQL, so maybe there's still hope that they can be a Real Business someday.
Also, just because a "real business" like Walmart can cope using a relational database doesn't disqualify any business that can't from being "real", that's just dumb. Even where it is technically possible, there are cases when the economics of running the business preclude the costs of using say Oracle.
So you've magically changed your backend from MySQL to Cassandra. Stuff will just work now, right? Well, no. Did you know that Cassandra requires a restart when you change the column family definition? Yeah, the MySQL developers actually had to think out how ALTER TABLE works, but according to Cassandra, that's a hard problem that has very little business value. Right.
I had considered trying to explain here how the differing use-cases and data-model made this less of a problem than Ted perceived it to be, but it's probably easier to just point out that it's basically fixed (see CASSANDRA-44).
I'm not just singling out Cassandra - by replacing MySQL or Postgres with a different, new data store, you have traded a well-enumerated list of limitations and warts for a newer, poorly understood list of limitations and warts, and that is a huge business risk.
I can't speak for other NoSQL projects, but I can assure you that if you have a work-load that can be reasonably accommodated by MySQL or Postgres, then that is what we will recommend you use. For those that can't, they're just going to have to live with a newer, less understood list of limitations and warts, because otherwise there is no business.
The sooner your company admits [that you are not Google], the sooner you can get down to some real work. Developing the app for Google-sized scale is a waste of your time, plus, there is no way you will get it right. Absolutely none. It's not that you're not smart enough, it's that you do not have the experience to know what problems you will see at scale.
The takeaways here I believe are, don't prematurely optimize, Google alone has the scale to justify distributed systems, and you are dumb. One out of three, not bad.
NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL. In the meantime, DBAs should not be worried, because any company that has the resources to hire a DBA is likely has decision makers who understand business reality.
Any company that has decision makers who understand reality will know to use the right tool for the right job.
Categories: cassandra nosql
相關文章
- 冷靜面對“元宇宙”熱潮QCQ元宇宙
- 對RESTful API的個人看法RESTAPI
- 對於Lumen和Laravel的看法Laravel
- 我對組隊學習的看法
- 我對部落格的理解和看法
- 對圖靈社群改版的小看法圖靈
- 對MVP和MVVM的一點看法MVPMVVM
- 我對軟體測試的看法
- DDD提出者Eric Evans承認不足,希望DDD語言不斷改進 - infoQ
- 對 Guice Interceptor 的一點 自己 的看法GUI
- 對Rust的不好看法 - chrisdoneRust
- 一個Python開發者對鴻蒙的看法Python鴻蒙
- 我對中國科技行業的看法(譯文)行業
- 大佬對 WEB 自動化測試的看法Web
- 路人開發對測試人員的看法
- 談談我對996.icu的看法996
- 我對技術潮流的一些看法
- 益普索:全球對AI的看法和期望AI
- 對於iOS效能優化的一點看法iOS優化
- 各位談談對java web start的看法吧JavaWeb
- 我對"系統=流程+表單"的看法 (轉)
- 面試官:說說你對NoSQL的瞭解,為什麼要有NoSQL面試SQL
- 線段樹 hate it
- Java 8 併發篇 - 冷靜分析 Synchronized(上)Javasynchronized
- Java 8 併發篇 - 冷靜分析 Synchronized(下)Javasynchronized
- CNNIC:醫生集團,發展路上需冷靜CNN
- 瑣碎的想法(三)對Java的批評的看法Java
- 冷靜的思考和快樂的吐槽——《黑客與畫家》黑客
- 聊一聊我對測試開發的看法
- 關於我對c#的一些看法C#
- 我對專案管理的一點看法1(轉)專案管理
- 我對專案管理的一點看法 2(轉)專案管理
- 我對Red Flag Desktop 5.0的個人看法(轉)
- 陳星漢:我希望改變人們對遊戲的看法遊戲
- 我對前端工程師這個職業的看法前端工程師
- 我對大家尋求oracle培訓的一點看法Oracle
- 歐盟冷對微軟“API”開放微軟API
- Generic:型別和值之間的對映 (轉)型別