Help needed with several engines use case [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Database Administrators Stack Exchange.

Closed 3 months ago.

Improve this question

We are developing an app, aprox 50k RPM read, 1k RPM write, it ask via key and get a JSON. The search is always made by key. I'm inclined to use one MySQL 8 table with a Id field and JSON field with innodb. Seems simple, cheap and fast accessing by index. Each index can have n rows (30 max), total size of table less than 100gb. Response time is important, I think 2-10ms are achievable on MySQL. The other, more expensive options that I have are DynamoDB and ElasticSearh (can't use another tool). Can't find a comparison for this use case to help me know if I'm in the correct path. Do you see any cons of using MySql or I'm missing something? Thanks!!

Answer 1

So any of those options EXCEPT ElasticSearch will probably work ok for you (equal hardware under the hood considered).

ElasticSearch is quite possibly the opposite use case from what you described. It's primarily best for tokenizing full text (like parsing email messages for example) and searching it efficiently, you mentioned your use case will always read by key.

A NoSQL database system or DynamoDB are actually rather fitting for your use case because of two things you mentioned: always reading by key, and storing the actual data in JSON format which allows for semi-structured, unstructured, and varying structured data. So this would be my first choice (might want to look into read limitations of DynamoDB vs other NoSQL database systems, as I thought I recall it was a little more limited based on how it was designed).

Otherwise MySQL should be able to handle your use case ok as well, being a modern RDBMS, but it wasn't really designed for your use case (serving the data only by the key and storing it all in a JSON format). It's a relational database system and therefore was designed for normalized schemas with Tables and relationships between those Tables.