Простой ответ заключается в том, что простого ответа на подобные проблемы не существует, единственный способ узнать, что работает для вашего сценария, - это потратить на него время НИОКР.
На этот вопрос сложно ответить, поскольку требования к производительности не прописаны в ОП.Похоже, это 75 миллионов записей в год для ряда клиентов со скоростью записи num_customers * 1 минута (что мало), но у меня нет данных о требуемой производительности чтения / запроса.
Фактически у вас уже есть база данных sharded , использующая горизонтальное разбиение , потому что вы храните каждого клиента в отдельной таблице.Это хорошо и увеличит производительность.Однако вы еще не установили, что у вас есть проблема с производительностью, поэтому ее необходимо измерить и оценить размер проблемы, прежде чем вы сможете ее исправить.
База данных NoSQL действительно является хорошим способом решения проблем производительности страдиционная СУБД, но она не обеспечивает автоматическую масштабируемость и не является общим решением.Вам нужно найти решение проблемы с производительностью, а затем спроектировать модель данных (nosqL), чтобы обеспечить решение.
В зависимости от того, чего вы пытаетесь достичь, я посмотрю на MongoDB , Apache Cassandra , Apache HBase или Hibari .
Помните, что NoSQL - это неопределенный термин, обычно охватывающий
- Приложения, которые требуют высокой производительности при чтении или записи.Часто жертвует производительностью чтения или записи за счет другого.
- Распределение и масштабируемость
- Различные методы сохранения (RAM / Disk)
- Более структурированный / определенный шаблон доступаусложнение специальных запросов.
Итак, во-первых, я посмотрю, сможет ли традиционная СУБД достичь требуемой производительности, используя все доступные методы, получить копию High PerformanceMySQL и прочитайте MySQL Performance Blog .
Rev1:
В свете ваших комментариев я думаю, что будет справедливо сказать, что вы можете достичь того, чего хотите, с помощьюодин из вышеперечисленных движков NOSQL.
Моя основная рекомендация будет заключаться в том, чтобы спроектировать и внедрить вашу модель данных, а то, что вы используете в данный момент, не совсем правильно.
Итак, посмотрите на Entity-attribute-Значение модели как мне кажется, это именно то, что вам нужно.
Прежде чем вы решите, какую технологию использовать, вам нужно получить правильную модель данных, поскольку честное динамическое изменение схем не является моделью данных.
Я бы использовал традиционную базу данных SQL для проверкии протестируйте новую модель данных, поскольку инструменты управления лучше, и, как правило, проще работать со схемами, когда вы уточняете модель данных.