ТОП-10 систем управления базами данных в 2019 году

Умение выбрать СУБД важно при разработке любого ПО. Мы собрали 10 систем управления базами данных и разобрались в их преимуществах.

Популярные системы управления базами данных

	Разработчик	Лицензия	Написана на
Oracle	Oracle Corporation	Проприетарная	Assembly, C, C++
MySQL	Oracle Corporation	GPL v2 или проприетарная	C, C++
Microsoft SQL Server	Microsoft Corporation	Проприетарная	C, C++
PostgreSQL	PostgreSQL Global Development Group	Лицензия PostgreSQL (бесплатное ПО с открытым исходным кодом, либеральная лицензия)	C
MongoDB	MongoDB Inc.	Различные варианты лицензирования	C++, C, JavaScript
DB2	IBM	Проприетарная EULA	Assembly, C, C++
Microsoft Access	Microsoft Corporation	Пробное ПО
Redis	Salvatore Sanfilippo	Лицензия BSD	ANSI C

Рейтинг СУБД

SQL-базы данных

1. Oracle

Oracle RDBMS (она же Oracle Database) на первом месте среди СУБД. Система популярна у разработчиков, проста в использовании, у нее понятная документация, поддержка длинных наименований, JSON, улучшенный тег списка и Oracle Cloud.

• Разработчик: Oracle Corporation
• Написана на:Assembly, C, C++
• Блог: Oracle NoSQL
• Скачать: Oracle NoSQL
• Последняя версия: 18.3

Особенности

• Обрабатывает большие данные.
• Поддерживает SQL, к нему можно получить доступ из реляционных БД Oracle.
• Oracle NoSQL Database с Java/C API для чтения и записи данных.

2. MySQL

MySQL работает на Linux, Windows, OSX, FreeBSD и Solaris. Можно начать работать с бесплатным сервером, а затем перейти на коммерческую версию. Лицензия GPL с открытым исходным кодом позволяет модифицировать ПО MySQL.

Эта система управления базами данных использует стандартную форму SQL. Утилиты для проектирования таблиц имеют интуитивно понятный интерфейс. MySQL поддерживает до 50 миллионов строк в таблице. Предельный размер файла для таблицы по умолчанию 4 ГБ, но его можно увеличить. Поддерживает секционирование и репликацию, а также Xpath и хранимые процедуры, триггеры и представления.

• Разработчик: Oracle Corporation
• Написана на C, C++
• Последняя версия: 8.0.16
• Скачать: MySql

Особенности

• Масштабируемость.
• Лёгкость использования.
• Безопасность.
• Поддержка Novell Cluster.
• Скорость.
• Поддержка многих операционных систем .

3. Microsoft SQL Server

Самая популярная коммерческая СУБД. Она привязана к Windows, но это плюс, если вы пользуетесь продуктами Microsoft. Зависит от платформы. И графический интерфейс, и программное обеспечение основаны на командах. Поддерживает SQL, непроцедурные, нечувствительные к регистру и общие языки баз данных.

Особенности

• Высокая производительность.
• Зависимость от платформы.
• Возможность установить разные версии на одном компьютере.
• Генерация скриптов для перемещения данных.

4. PosgreSQL

Масштабируемая объектно-реляционная база данных, работающая на Linux, Windows, OSX и некоторых других системах. В PostgreSQL 10 есть такие функции, как логическая репликация, декларативное разбиение таблиц, улучшенные параллельные запросы, более безопасная аутентификация по паролю на основе SCRAM-SHA-256.

• Разработчик: PostgreSQL Global Development Group
• Написана на C
• Используется в компаниях: Apple, Cisco, Fujitsu, Skype, and IMDb
• Последняя версия: 11.2
• Блог: PostgreSQL
• Скачать: PostgreSQL

Особенности

• Поддержка табличных пространств, а также хранимых процедур, объединений, представлений и триггеров.
• Восстановление на момент времени (PITR).
• Асинхронная репликация.

NoSQL-базы данных

5. MongoDB

Самая популярная NoSQL система управления базами данных. Лучше всего подходит для динамических запросов и определения индексов. Гибкая структура, которую можно модифицировать и расширять. Поддерживает Linux, OSX и Windows, но размер БД ограничен 2,5 ГБ в 32-битных системах. Использует платформы хранения MMAPv1 и WiredTiger.

• Разработчик: MongoDB Inc. в 2007
• Написана на C++
• Последняя версия: 4.1.9
• Блог: MongoDB
• Скачать: MongoDB

Особенности

• Высокая производительность.
• Автоматическая фрагментация.
• Работа на нескольких серверах.
• Поддержка репликации Master-Slave.
• Данные хранятся в форме документов JSON.
• Возможность индексировать все поля в документе.
• Поддержка поиска по регулярным выражениям.

6. DB2

Работает на Linux, UNIX, Windows и мейнфреймах. Эта СУБД идеально подходит для хост-сред IBM. Версию DB2 Express-C нельзя использовать в средах высокой доступности (при репликации, кластеризации типа active-passive и при работе с синхронизируемым доступом к разделяемым данным).

• Разработчик: IBM
• Написана на C, C++, Assembly
• Последняя версия: 11.1
• Скачать: DB2

Особенности DB2 11.1

• Улучшенное встроенное шифрование.
• Упрощённая установка и развёртывание.

7. Microsoft Access

Система управления базами данных от Microsoft, которая сочетает в себе реляционное ядро БД Microsoft Jet с графическим интерфейсом пользователя и инструментами разработки ПО.

Идеально подходит для начала работы с данными, но производительность не рассчитана на большие проекты. В MS Access можно использовать C, C#, C++, Java, VBA и Visual Rudimental.NET. Access хранит все таблицы БД, запросы, формы, отчёты, макросы и модули в базе данных Access Jet в виде одного файла.

• Разработчик: Microsoft Corporation
• Последняя версия: 16.0
• Скачать: Microsoft Access

Особенности

• Можно использовать VBA для создания многофункциональных решений с расширенными возможностями управления данными и пользовательским контролем.
• Импорт и экспорт в форматы Excel, Outlook, ASCII, dBase, Paradox, FoxPro, SQL Server и Oracle.
• Формат базы данных Jet.

8. Cassandra

СУБД активно используется в банковском деле, финансах, а также в Facebook и Twitter. Поддерживает Windows, Linux и OSX. Для запросов к БД Cassandra используется SQL-подобный язык — Cassandra Query Language (CQL).

• Разработчик: Apache Software Foundation
• Написана на: Java
• Последняя версия: 3.11.4
• Блог: Cassandra
• Скачать: Cassandra

Особенности

• Линейная масштабируемость.
• Быстрое время отклика.
• Поддержка MapReduce и Apache Hadoop.
• Максимальная гибкость.
• P2P архитектура.

9. Redis

Redis или Remote Dictionary Server — СУБД с открытым исходным кодом, которая снабжена механизмами журналирования и снимков. Поддерживаются списки, строки, хэши, наборы. Используется для БД, брокеров сообщений и кэшей. Все операции в Redis атомарные. Система написана на языке C и поддерживается практически всеми языками программирования.

• Разработчик: Salvatore Sanfilippo
• Последняя версия: 5.0.5
• Блог: Redis
• Скачать: Redis

Особенности

• Автоматическая обработка отказа.
• Транзакции.
• Сценарии LUA.
• Вытеснение LRU-ключей.
• Поддержка Publish/Subscribe.

10. Elasticsearch

Легко масштабируемая поисковая система корпоративного уровня с открытым исходным кодом. Благодаря обширному и продуманному API обеспечивает чрезвычайно быстрый поиск, работает в том числе с приложениями для обнаружения данных. Используется такими компаниями, как Википедия, The Guardian, StackOverflow, GitHub. ElasticSearch позволяет создавать копии индексов и сегментов.

• Разработчик: Elastic NV
• Написана на Java
• Последняя версия: 7.2.0
• Блог: Elasticsearch
• Скачать: Elasticsearch

Особенности

• Масштабируемость вплоть до нескольких петабайт структурированных и неструктурированных данных.
• Многопользовательская поддержка.
• Масштабируемый поиск, поиск в режиме реального времени.

Рейтинги СУБД

Рейтинг			СУБД	Модель базы данных	Балл
Июль 2017	Июнь 2017	Июль 2016			Июль 2017	Июнь 2017	Июль 2016
1	1	1	Oracle	Реляционная СУБД	1374.88	+23.11	-66.65
2	2	2	MySQL	Реляционная СУБД	1349.11	+3.8	-14.18
3	3	3	Microsoft SQL Server	Реляционная СУБД	1226	+27.03	+33.11
4	4	5↑	PostgreSQL	Реляционная СУБД	369.44	+0.89	+58.28
5	5	4↓	MongoDB	Документная СУБД	332.77	-2.23	+17.77
6	6	6	DB2	Реляционная СУБД	191.25	+3.74	+6.17
7	7	8↑	Microsoft Access	Реляционная СУБД	126.13	-0.42	+1.23
8	8	7↓	Cassandra	СУБД типа BigTable	124.12	-0.0	-6.58
9	9	10↑	Redis	СУБД типа «ключ-значение»	121.51	+2.63	+13.48
10	11↑	11↑	Elasticsearch	Поисковая система	115.98	+4.42	+27.36

 

А какую СУБД предпочитаете вы? Аргументируйте свой выбор 😉

ТОП 5 популярных систем управления базами данных (СУБД) в 2020 | Info-Comp.ru

Приветствую всех посетителей сайта Info-Comp.ru! Сегодня мы с Вами узнаем, какие системы управления базами данных (СУБД) являются самыми популярными в 2020 году. Иными словами, в этом материале представлен рейтинг популярности СУБД, и мы рассмотрим ТОП 5 баз данных, которые находится на вершине данного рейтинга.

На чем основан данный рейтинг

В одной из прошлых статей – ТОП 7 популярных языков программирования, за основу мы брали достаточно много различных источников, но если говорить про базы данных, то таких источников гораздо меньше. Однако все равно существуют официальные рейтинги и другие аналитические данные, которые показывают популярность СУБД.

Некоторые рейтинги основываются на частоте упоминаний в запросах поисковых систем, т.е. если люди чаще ищут информацию по БД в интернете, значит, можно сделать вывод, что эта база данных пользуется популярностью. А некоторые ориентируются на количество заданных вопросов по конкретной базе на специализированных форумах, т.е. если больше вопросов задают по работе с какой-то конкретной базой данных, значит ее используют много людей, и она популярна.

В любом случае такие рейтинги, как, впрочем, и рейтинги языков программирования, не отражают точную фактическую популярность той или иной СУБД, так как основываются на каком-то одном показателе. И как результат, рейтинги просто противоречат друг другу.

Однако если проанализировать все источники, то можно определить несколько баз данных, которые наиболее часто встречаются в топе каждого рейтинга, тем более что состав ТОПа баз данных во всех рейтингах примерно одинаковый, только места у СУБД разные.

На основе всех этих источников можно сделать вывод, что определённые базы данных действительно являются популярными по всем показателям, а не только по какому-то одному.

Таким образом, чтобы упростить Вам задачу в анализе всей необходимой информации, в этом материале представлен ТОП 5 СУБД, который основан на данных всех популярных официальных рейтингов и показателей за предыдущий год.

Источники данных (официальные показатели и рейтинги СУБД):

• PYPL (PopularitY of Programming Language) – рейтинг основывается на данных поисковой системы Google;
• Stack Overflow – основывается на количестве вопросов, связанных с базой данных;
• DB-Engines – данный рейтинг основывается на многих показателях:
  • Данные поисковых систем Google, Bing и Yandex;
  • Количество вопросов на Stack Overflow и DBA Stack Exchange;
  • Количество предложений о работе на Indeed и Simply Hired, в которых упоминается система;
  • Количество профилей в профессиональных сетях LinkedIn и Upwork, в которых упоминается система;
  • Количество упоминаний в Twitter.
• Кроме все прочего учитывались данные компании РУССОФТ, которая проводила специальные опросы софтверных компаний об используемых инструментах программирования, и в частности СУБД.

MySQL

MySQL – бесплатная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет компания Oracle. MySQL широкое распространение получила в интернете, как система хранения данных у сайтов, иными словами, подавляющее большинство сайтов хранят свои данные в базе MySQL. Поэтому не удивительно, что MySQL занимает лидирующую строчку нашего рейтинга.

В рейтинге Stack Overflow MySQL занимает первое место, т.е. программисты больше всего задают вопросы, связанные именно с MySQL.

Во всех остальных рейтингах MySQL уверенно занимает вторую строчку, и это один из самых стабильных результатов среди всех наших сегодняшних участников. Именно поэтому MySQL и занимает первую строчку рейтинга самой популярной СУБД.

Microsoft SQL Server

Microsoft SQL Server – это система управления реляционными базами данных, разработанная компанией Microsoft. Ее активно используют в корпоративном секторе, особенно в крупных компаниях. И это не просто СУБД – это целый комплекс приложений, позволяющий не только хранить и модифицировать данные, но еще и анализировать их, осуществлять безопасность этих данных и многое другое.

По результатам опросов компании РУССОФТ, именно Microsoft SQL Server чаще всего используют софтверные организации.

В остальных рейтингах Microsoft SQL Server уверенно занимает третью строчку, поэтому данной СУБД мы отдаем вторую строчку нашего рейтинга.

Oracle

Oracle Database – это система управления базами данных от компании Oracle. Эта СУБД также активно используется крупными компаниями и стоит немаленьких денег, но взамен она предоставляет огромный функционал и надёжность. Поэтому Oracle Database и Microsoft SQL Server являются серьезными конкурентами друг другу.

Результаты Oracle в рейтингах не так однозначны, например, по версии PYPL и DB-Engines, Oracle Database занимает первое место, по версии Stack Overflow Oracle находится на восьмой позиции, по результатам опросов софтверных компаний Oracle на четвертом месте по популярности.

Если учитывать только пару рейтингов, Oracle можно поставить даже на первое место, однако если принять во внимания все результаты, то Oracle поставить на первое место нельзя, поэтому в нашем рейтинге эта СУБД занимает третью строчку.

PostgreSQL

PostgreSQL – это бесплатная реляционная система управления базами данных. Ее активно используют на UNIX-подобных платформах, для реализации как малых и средних, так и крупных проектов.

Самый лучший результат у PostgreSQL в рейтингах по версии Stack Overflow, где она занимает вторую строчку после MySQL.

PYPL и DB-Engines ставят PostgreSQL на четвертое место, опросы показывают, что PostgreSQL стоит на третьем месте по популярности, таким образом, PostgreSQL уверенно занимает четвертую позицию нашего рейтинга.

MongoDB

MongoDB – это документоориентированная система управления базами данных с открытым исходным кодом, не требующая описания схемы таблиц. MongoDB – классифицируется как NoSQL и использует JSON-подобные документы и схему базы данных.

Если все четыре предыдущих СУБД на слуху у большинства IT специалистов, то о MongoDB слышали не многие. Но она уверенно занимает 5 строчку практически во всех рейтингах.

И как результат, в нашем рейтинге она также занимает 5 позицию.

Заключение

Вот мы с Вами и рассмотрели 5 самых популярных СУБД, которые активно используются во всем мире.

И на сегодня это все, надеюсь, материал был Вам интересен, пока!

Выбор надежной БД в высоконагруженном проекте / Habr

Привет Хабр! Сегодня клиенты Pyrus заливают нам около 60GB данных ежедневно. Наша технология хранения информации многократно доказала свою надежность. Компания развивается, и мы озаботились вопросом выбора БД на ближайшие 10 лет. Наша цель — быть готовыми к 100-кратному росту и при этом не менять платформу каждые 2-3 года. Конкуренция на рынке баз данных развита: представлено много решений, большая часть из них open source и/или бесплатные. Ищем «идеальное решение»™ для нашей задачи.

Требования

Главное требование к БД — чтобы не теряла информацию. Удивительно, но многие базы данных не удовлетворяют этому ключевому требованию: даже проверенные годами решения дают сбои в несложных сценариях (примеры: раз, два). Мы хотим сохранять избыточность во время отключения любого сервера на техобслуживание, Это означает, что любая информация должна храниться минимум на 3х серверах.

Другое требование к БД — способность использовать современное железо. Через 10 лет в процессорах будет более 100 ядер, оперативная память будет интегрирована в сами чипы, а стоимость флеш-памяти заметно снизится. Что не изменится за 10 лет — это скорость света. Сетевой пакет из Европы в Америку идет около 100мс (RTT), и это время довольно близко к теоретическому пределу. Поэтому будущие дата-центры — это кластеры мощных числодробилок с быстрой сетью внутри, соединенные по всему миру каналами связи с высокой задержкой (high latency links). Современная БД должна поддерживать синхронную репликацию внутри дата-центра и асинхронную между дата-центрами.

При анализе мы ориентировались на утверждения самих поставщиков БД, результаты независимых тестов (когда они есть) и кейсы реального использования (много примеров есть на highscalabitility.com). Мы исключили из рассмотрения встроенные (embedded) базы данных, поскольку у них нет автоматической репликации по сети.

Коммерческие SQL-базы данных

Самые известные представители этого сегмента — Microsoft SQL Server и Oracle Database. Это отличные, проверенные временем продукты, а с последними инновациями — in-memory tables и column stores — на полную используют возможности современного железа. Обе БД поддерживают технологии кластеризации, и у обеих богатые возможности языка SQL (хотя у каждой — свой диалект).

Обе БД можно лицензировать по модели “цена за ядро процессора” и тогда цена не зависит от числа пользователей. Проанализировав нашу нагрузку и сделав прогноз по росту, мы посчитали, что стоимость будет несоразмерно большой и решили изучить альтернативы.

SQL-базы данных с открытым кодом

MySQL и PostgreSQL — самые известные представители этой группы — оптимальный выбор для большинства задач. Обе поддерживают кластеризацию, есть примеры использования в больших проектах и даже миграции с одной на другую в больших проектах. Пожалуй, основным минусом для нас является ручной шардинг и, как следствие, отсутствие автоматической ребалансировки кластера.

В нашей системе в качестве ключа шардинга — параметра, по которому определяется на каком сервере кластера хранить элемент данных, — естественно выбрать организацию (группу пользователей). Однако некоторые организации остаются маленькими — 1-2 пользователя, а другие по мере работы в сервисе вырастают до десятков тысяч пользователей. Распределение нагрузки по такому ключу рано или поздно приведет к переполнению одних серверов в кластере и недозагруженности других. В этот момент потребуется ребалансировка — то есть разделение ноды кластера на две. Эту работу сложно делать на работающем 24×7 кластере без потери надежности.

NoSQL-базы данных

Модное в 2000-е годы движение NoSQL сейчас переживает период зрелости. Все игроки хорошо известны и обладают своими сторонниками. Созданные при бурном росте интернета, эти БД развивались для соответствующих задач, например, для хранения и обработки миллиардов неструктурированных документов. Многие решения декларируют “eventual consistency”, что означает отказ от строгого “C” в CAP-теореме. Мы не можем терять данные клиентов, поэтому для нас такой компромисс неприемлем.

Некоторые NoSQL-решения снижают доступность (“A”) и декларируют “CP”, например, Cassandra. Это подходит для наших задач, однако мы были удивлены отсутствием row-level consistency: две совпавших по времени записи в разные колонки одной строки могут привести к порче данных. И хотя такого уровня глюков не ожидаешь от БД, вокруг этой проблемы можно найти обходной путь (например, модифицировать строки только целиком), и мы взяли Cassandra на заметку.

Облачные базы данных

Про эту категорию можно написать отдельный обзор. У каждого из основных PaaS-игроков (Amazon, Google и Microsoft) есть 6-8 разных предложений для хранения структурированных данных (и еще много сервисов для хранения BLOBS). Под любой тип нагрузки можно подобрать готовое решение.

Мы отказались от облачных хранилищ по соображениям хранения персональных данных. Наши клиенты находятся в разных странах, а ни один сервис не предлагает хранение ПДн во всех странах мира в соответствии с локальным законодательством. Другой причиной была сильная зависимость от конкретного вендора — вы не можете взять их технологию и развернуть на своем железе. Если появится желание уйти от вендора (при повышении цен или снижении надежности), проект миграции может быть очень долгим. У Dropbox ушло более 2 лет на переезд из облака Amazon в собственное хранилище.

NewSQL-базы данных

Популярность языка SQL и развитие “железа” породили новое движение — распределенные базы данных с языком запросов SQL. Среди них выделяется Google Spanner, которая гарантирует linearizability — глобальный порядок записи всех транзакций. Чтобы решить такую задачу в масштабах планеты, нужно синхронизировать время на серверах БД по всему миру. Компания Google использует для этого атомные часы, а для резерва — GPS-приемники.

Однако для простых смертных атомные часы пока остаются роскошью, поэтому авторы Spanner построили аналогичную БД с несколько меньшими гарантиями на порядок транзакций, но достаточными для большинства приложений. Эта БД называется CockroachDB (от англ. “таракан”) и своим названием олицетворяет живучесть кластера при сбоях железа или связей между дата-центрами. CockroachDB предоставляет полноценные распределенные транзакции и автоматическую ребалансировку кластера при потере ноды, что, вкупе с привычным языком запросов SQL, выгодно отличает ее от Cassandra. Из недостатков стоит отметить отсутствие полнотекстовых индексов и сравнительную молодость решения.

Move code to data

Часто бизнес-логика располагается на сервере приложений, который получает запросы клиентов и для их обработки обращается за данными к серверу БД. Когда данных много, передача их по сети от сервера БД начинает занимать существенное время. Отсюда появляются естественное желание перенести всю обработку внутрь БД и технологии типа Apache Hadoop, которые позволяют программировать такие задачи. (Обыкновенные реляционные БД также позволяют писать логику запросов внутри, на хранимых процедурах, но многие разработчики их не любят, поскольку их неудобно отлаживать.)

В последнее время набирает популярность идея совмещения серверов приложений и БД для near real-time OLTP-нагрузок, и появляются соответствующие технологии, например, Tarantool. Очень подкупает архитектура без блокировок “cooperative multitasking”, хотя писать такие приложения сложнее. Останавливает язык программирования Lua — хотя он и популярен среди разработчиков игр, но закрытый, развивается медленно и в нашей команде нет людей с реальным опытом его использования.

Заключение

Сегодня мы считаем CockroachDB самым перспективным вариантом. Нам импонирует открытость компании (исходный код БД выложен на github) и качество документации (архитектурные и другие ключевые решения вплоть до низкоуровнего формата хранения данных опубликованы на сайте). Мы следим за эволюцией продукта и будем рады обмену мнениями с коллегами, которые используют эту БД в production.

А пока мы стартуем пилотный проект и будем делиться с вами опытом использования в боевом режиме.

БД для хранения сообщений чата, какую выбрать? — Хабр Q&A

Добрый день, делаю проект на Yii2, в нем уже реализован чат на комет сервере чат уже полностью работает, пользователи могут общаться только в приватных беседах т.е. только 2 пользователя друг с другом. При отправке сообщения, оно улетает аяксом в php скрипт, валидируется по определенным правилам и если все ок, записывает в таблицу бд и возвращает успех на клиентскую часть после чего уже сообщение попадает в окошко чата.

Структура бд:
tbl_dialog:
dialog_id — id Диалога
dialog_one_user_id — id первого юзера
dialog_two_user_id — id второго юзера
dialog_time — время создания диалога

tbl_message
chat_messages_id — id сообщения
chat_messages_text — текст сообщения
chat_messages_fk_dialog_id — id Диалога к которому относится сообщение
chat_messages_fk_user_id — id отправителя
chat_messages_fk_to_user_id — id получателя
chat_messages_ip — ip отправителя
chat_messages_isRead — прочитано ли сообщение получателем
chat_messages_isVisible_one_user — видимость сообщение для первого юзера
chat_messages_isVisible_two_user — видимость сообщение для первого юзера (для возможности отчисти сообщений, если просто удалять тогда сообщение пропадет из истории у обоих юзеров)
chat_messages_time — время отправки сообщения

Вся система работает с бд MySQL — InnoDB, сообщения пишутся в бд при каждой отправке (INSERT), пока сервис еще не запущен, сообщений мало (только мои тестовые) все работает шустро, но вот когда запущу и количество сообщений перевалит за несколько миллионов, что будет тогда с моей бд? Начнутся жесткие тормоза при select и insert?

Вот пока не поздно думаю стоит ли переписывать хранение сообщений на другую NoSQL БД, с ними не работал никогда, почитал доки и на первый взгляд ничего сложного…

В голове вертятся 2 варианта реализации:
1) перевести табличку tbl_message в коллекцию MongoDB и так же писать туда сообщения при каждой отправке (т.е. пользователь отправил 1 сообщение и мы его сразу в бд записали, по одной записи делать буду и так каждое сообщение). Как Mongo будет вести себя при вставке сообщения, когда в коллекции будет за 20 млн записей? Правильная ли эта схема?

1) Записывать каждое сообщение в память в виде массива сообщений (memcached или redis или еще что то — посоветуйте) и по крону допустим каждую минуту или 5 мин брать весь массив сообщений, писать через транзакцию в MySQL, далее чистим массив сообщений для новых записей. Так получается что не будет несколько инсертов в секунду, т.к. сообщения будут храниться в памяти. Но тут опять засада, сможет ли MySQL нормально работать с огромной таблицей 20млн записей?

Сам текст сообщений очень короткий, что то типа «Привет! Как дела?»