SQL数据库列中的数组 - 或 - 一个键/值noSQL存储？

Question

I thank you in advance for your time. Your experience sharing is invaluable.

Assume a situation where 4 users can submit posts and upvote others posts. In a database, which from the above approaches will be the best regarding query execution time? Is it the 3 columns SQL database or the 2 columns NoSQL key/value store?

An example of querying: get upvoters of post_3.

Thank you

first approach (MySQL for example)

second approach

Edit(based only on John Tseng answer)

create table post (post_id int, author_id int); create table upvote (user_id int, post_id int).

Should I conclude that:

2 tables (=3 reads) is better than long string read from one table processed with php?

I want to note that optimizing the speed (or at least learning howto) before implementing the project is something I feel important. I dont want that my tables become TBs in the future and performing slow, because redesign will be risky and need big work. I am scared of moving one big column from a table to another. That's why I am spending a lot of time to find the best design for my database and asking from the beginning if is it good to use key/value store. Do I missunderstand key-value stores, are they not used at the beginning on the first machine.

The way you store your data is very important, and you should make it logical before optimizing for speed.

Why not to create a logical design which will be easily optimized for speed in the future?

From your invaluable answer do I need to understand that good design of SQL database is the only need and use of Key-Value store will be easy after.

Answer 1

If you are asking for the query execution time for this one query, then it's definitely the schema where only one read is necessary (first approach).

However, I don't think this is a good way to store your data. What if some day, you want to query for: does user 3 upvote any of the posts by user 1?

I would make two tables:

create table post (post_id int, author_id int); create table upvote (user_id int, post_id int);

This will make your example query slower, but I think you should not be optimizing for speed. The way you store your data is very important, and you should make it logical before optimizing for speed. You will have a large arsenal of ways to make your database faster without resorting to storing your data in odd ways.

Sure when you get to thousands of requests per second, you will want to do some denormalization and NoSQL, but I think you should stay away from those kinds of things in your initial design.

When people say NoSQL doesn't scale, they mean databases in the order of TBs and requests in the order of thousands per second. In a few years, they will mean tens of TBs, and ten thousand requests per second. It is already possible to make relational databases handle tens of TBs and ten thousand requests per second with very beefy machines. It just will be a little more affordable in a few years.

In conclusion, make your initial design in a relational database, normalizing everything textbook style. When you start to max out on RAM (after other relational database optimizations), then you can think about these issues.

EDIT

For this one query, it is true that reading one row from the table is faster. However, a good database design should be flexible enough to accomodate multiple queries, not just one. In your case, once you have thousands of followers or even millions of upvotes, you will have some serious issues. To modify an individual upvote, you will need to do a large amount of processing. To find any individual update, you need to parse the whole string.

While I understand your desire to optimize for speed right at the beginning, many people's experiences have shown that it is much better to have logical code than code that centers purely on performance metrics. As we have seen in this short example, because you speed up this query, you are dramatically slowing down other queries.

Also, it is much easier to understand SQL structures than NoSQL structures. You should definitely learn to do things the SQL way before you learn the NoSQL way. One reason is that NoSQL is anything that's not SQL, and there's a ton of choices.

Back to this particular query. With the right index, the query will issue three successive reads, which will have very similar performance to a single read. I think the right way to speed up this query is not to store the data in your database in an awkward way, but to leave the awkward storage to your caching layer. You would query the database for the correct answer to the query, and then store that in your cache. Every subsequent read would the get the data from the cache. The cache would be denormalized like:

key: Post_3_upvotes value: [1, 3]

The difference between this and storing all your data in a key/value store is that modifications would be done to the relational database which will be good at modifications. Modifying the key/value store with many simultaneous users will get you into bigger issues than performance.