TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

MySQL is a Better NoSQL

96 点作者 yoava超过 9 年前

23 条评论

JonahBraun超过 9 年前
Interesting that he advocates MySQL. PostgreSQL can index and interact with the JSON stored in it&#x27;s columns, which make it a better choice as a NoSQL replacement.<p><a href="http:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;9.4&#x2F;static&#x2F;datatype-json.html" rel="nofollow">http:&#x2F;&#x2F;www.postgresql.org&#x2F;docs&#x2F;9.4&#x2F;static&#x2F;datatype-json.html</a>
评论 #10707839 未加载
评论 #10707832 未加载
hoodoof超过 9 年前
I did an extensive survey of NoSQL databases recently and for my particular requirements Postgres ended up being the best choice. I examined MySQL too in this particular survey. Can&#x27;t remember why but its JSON handling didn&#x27;t meet my needs.<p>Every time I consider alternative databases -and I&#x27;ve done so several times in the past ten years - I do a thorough examination and the answer always seems to come back to Postgres. I&#x27;m not a particular Postgres fanboy but the answer just ends up at the same place.
评论 #10707865 未加载
评论 #10708007 未加载
评论 #10708116 未加载
jhall1468超过 9 年前
I&#x27;m going to question your knowledge of the domain immediately when your solution to a problem is to take away all of the advantages of SQL without any of the benefits that Cassandra or Redis provide.<p>To me this is akin to saying we don&#x27;t need Haskell because Java now has lambda expressions.
评论 #10707946 未加载
评论 #10707893 未加载
DigitalSea超过 9 年前
MySQL is great and all, but if you want a better database that is considerably more powerful and supports NoSQL type scenarios: PostgreSQL. The fact that Postgres has supported working with JSON like key&#x2F;value store data for a while now and it is quite decent, as well as giving you other options if you decide you want the traditional approach of tables.
评论 #10707853 未加载
cortesoft超过 9 年前
I really hate any post that says &quot;you don&#x27;t really need this tool, this one does that job just fine for us&quot;<p>You don&#x27;t know my workload. You don&#x27;t know my requirements. It is ok to make a post saying that a specific tool is wrong for these use cases, or that you believe that many people using a tool don&#x27;t need it or would be better off with a different tool..... But don&#x27;t act like you know my workload.
评论 #10708118 未加载
tylermauthe超过 9 年前
<i>&gt; Fields only exist to be indexed. If a field is not needed for an index, store it in one blob&#x2F;text field (such as JSON or XML).</i><p>A cautionary tale... It can be tempting to store serialized objects in your DB. This can be very dangerous, both for debugging and for migrations. Your data is coupled to your application in subtle ways and you can get stale references if you store any relationships in the &quot;blob&quot;. JSON or XML isn&#x27;t so terrible, at least a human can read that -- using a true BLOB is a kiss of death. A database is a handy abstraction for storing data, I highly recommend that you use this abstraction (and all abstractions) for humans first and robots second.<p>Granted, this is an article about optimization and in that regard I&#x27;m sure it yields benefits. If you must squeeze every last drop of juice out of a MySQL server, then do this -- just know that it comes with a price.
halayli超过 9 年前
&gt; &quot;MongoDB, Cassandra, Redis, or Hadoop&quot;<p>Adding Hadoop in the mix tells me he doesn&#x27;t know what a NoSQL is.
评论 #10707849 未加载
评论 #10707859 未加载
chad_walters超过 9 年前
MySQL may work well for this small data set (200GB). Start working with 10s of TBs of data and you will start to understand why NoSQL stores were built.
评论 #10708096 未加载
评论 #10708666 未加载
评论 #10708493 未加载
评论 #10710370 未加载
评论 #10708105 未加载
avitzurel超过 9 年前
This is right and wrong in the same time. Not sure which more.<p>Storing JSON as TEXT is great, but you really only query the data based on the mySQL index.<p>What if you need to query based on the site_data?<p>This is really not NoSQL this is just a key value store with a JSON object that is not even native type to the database, you will still need to parse back&#x2F;forth.<p>What about updating the data? You need to get the object and then you need to parse it, change it and send it back marshalled to TEXT that MySQL can understand.<p>Even as a KV store, using MySQL simplifies a lot of things but there are MUCH better solutions out there.<p>[EDIT] One other thing that this fails to mention is that TEXT in MySQL will in most cases go to disk to get the &quot;document&quot; which will be slower.<p>In Wix case, getting a website and having all the data available this is most likely not relevant, but if you want to get multiple rows at a time, this will become a consideration for you.
评论 #10707847 未加载
评论 #10711995 未加载
评论 #10707956 未加载
评论 #10708140 未加载
aidos超过 9 年前
Quick question - I&#x27;m confused about the comment &quot;The nested query syntax ensures that we are doing only one round-trip to the database to run both SQL queries&quot;. Why is the nested syntax better than a regular join in this case?<p>Seems like a join would allow the query planner to decide how to carry out the query.
评论 #10708196 未加载
评论 #10713740 未加载
评论 #10709641 未加载
trustfundbaby超过 9 年前
Title feels a bit faceitous because the article&#x27;s use case is more akin to a key value store, vs nosql in the schemaless, mongodb&#x2F;cassandra sense.<p>Good write up though.
weddpros超过 9 年前
If sharding, rebalancing and partitions didn&#x27;t exist... And if 1600 rps were enough when nosql can reach 1M rps (600 times more)... And if that homemade replication infrastructure was as mature and supported as nosql dbs...<p>Then using MySQL as a nosql might work.
评论 #10708561 未加载
mbfg超过 9 年前
This use case seems to be highly read oriented, which is fine, but really diminishes the value of distributed &#x27;nosql&#x27; stores. The really hard thing to scale is massive writes. Cassandra&#x27;s big differentiator, for instance, is it&#x27;s ability to horizontally scale massively when it comes to writes. a million client writes per second, replicated over zones, type of performance.<p>Oh and by the way, &#x27;vertical&#x27; scaling is kind of a silly concept. That just means, &quot;i wasn&#x27;t an idiot&quot;.
seanwoods超过 9 年前
Reminds me of:<p><a href="http:&#x2F;&#x2F;backchannel.org&#x2F;blog&#x2F;friendfeed-schemaless-mysql" rel="nofollow">http:&#x2F;&#x2F;backchannel.org&#x2F;blog&#x2F;friendfeed-schemaless-mysql</a>
lemmsjid超过 9 年前
As this title demonstrates, NoSQL is no longer a useful term. (It was useful for a period of time when SQL-based RDBMs systems were quite predominant, so it could be used as a gross differentiator).<p>Now the best way to think about it is that there are database platforms with varying features, one of which is support for SQL. When you evaluate which platform to use, you should have a list of business-derived criteria, such as SQL support, support for various relational integrity constructs (i.e. foreign keys), latency for typical queries (e.g. Hive), fault tolerance, ACID compliance, partitioning schemes, read or write optimization, etc. and act accordingly.<p>&quot;NoSQL&quot; used to be shorthand for a vague subset of database features that usually involved relaxing data protection in favor of multi-server scalability, but now it just muddies the waters, especially as many NoSQL platforms now support SQL or a subset thereof.
评论 #10710392 未加载
rakoo超过 9 年前
Might as well go the full route:<p><pre><code> CREATE TABLE `sites` ( `site_id` varchar(50) NOT NULL, `owner_id` varchar(50) NOT NULL, `schema_version` varchar(10) NOT NULL DEFAULT &#x27;1.0&#x27;, `site_data` text NOT NULL, `last_update_date` bigint NOT NULL, `route` varchar(255) NOT NULL, PRIMARY KEY (`site_id`) ) &#x2F;*ENGINE=InnoDB DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=16*&#x2F;; select * from sites where route = ? </code></pre> No join (truly, this time), no need for transaction (whether in the DB or softly in the application). If you want improvements in performance you need to stop using your DB as a way to model your <i>data</i> and start using it as a way to model your <i>queries</i>. Considering that the <i>data</i> is already stored in the site_data field, they already started on this path.
carsongross超过 9 年前
This statement is nearly meaningless without context.<p>YesSQL is better than NoSQL <i>for some problems</i> (I happen to think many of them.)<p>NoSQL is better than YesSQL <i>for some problems</i> (I happen to think more of them than I thought a few years ago.)<p>I&#x27;m glad that YesSQL worked well for Wix in this case.
niutech超过 9 年前
This was done by FriendFeed back in 2009: <a href="https:&#x2F;&#x2F;backchannel.org&#x2F;blog&#x2F;friendfeed-schemaless-mysql" rel="nofollow">https:&#x2F;&#x2F;backchannel.org&#x2F;blog&#x2F;friendfeed-schemaless-mysql</a>
mkadlec超过 9 年前
What about ease of setup? I&#x27;d take the NoSql setup any day. If in need of a super light, super quick db that is for a &quot;non-enterprise&quot; application, it&#x27;s tough to beat NoSql...
评论 #10710374 未加载
评论 #10708594 未加载
dirkdk超过 9 年前
that mapping from routes to sites seems also great to be stored in a Memcached machine, as it is probably set once and then stays the same for months if not years. Memcached and MySQL is always a great combo
评论 #10710390 未加载
nfirvine超过 9 年前
&quot;Do not perform table alter commands. Table alter commands introduce locks and downtimes. Instead, use live migrations.&quot;<p>You know what avoids alter? Going schemaless.
评论 #10708052 未加载
评论 #10710383 未加载
sagivo超过 9 年前
Great post Yoav! Thanks for sharing
jonthepirate超过 9 年前
+1 for &quot;do not use joins&quot;
评论 #10708384 未加载