MySQL – это лучшая NoSQL-система

[velvetcat]

> В этой статье мы объясним, почему, по нашему мнению, использовать MySQL для хранения пар ключ-значение лучше, чем большинство специализированных NoSQL-систем

То, что Вы изобрели, ни разу не решает тех проблем, которые заставляют переходить на NoSQL.

[lesha_firs]

А вот у меня вопрос, какие основные принципы покрывает NoSql и почему реляционные базы данных уступают?
Я просто смотрю, вы разберитесь, мне просто кажется что при правильной архитектуре того-же postgres нет необходимости в NoSql.

Для меня NoSql это — что-то типа redis ключ-значение, для легкого кеша. Если я ошибаюсь, можно подробный ответ? или ссылки на литературу.

[Razaz]

Как вы слили все базы в один простой key-value :)
Тынц по базам

[xhumanoid]

а теперь главные вопросы которые почему-то остаются за кадром:

1. sharding — у вас он ручной,
1.1 что делать если клиенты в разных шардах растут с разной скоростью и у нас на одном шарде 100млн, а на другом 1млн записей?
1.2 как делать перебалансировку в случае если нам нужно добавить +1 сервер в кластер

2. fault tolerance
2.1 мультимастер еще нужно уметь настраивать, в master-slave при выпадении master тоже веселье

если у вас 1 мастер и пачка слейвов, так как нагрузка на запись минимальная, почти все это чтение, то вам конечно повезло,

но ведь nosql любят в первую очередь за то, что у вас ключи разбиты по бакетам которых заметно больше чем серверов и эти бакеты свободно мигрируют между узлами (решаем задачу 1 с балансировкой и добавлением новых узлов), а выпавшего мастера автоматически подхватывает кто-то другой (в hbase и mongodb на основе кворума, у cassandra вообще мастера нету) (решаем задачу сложности конфигурации для задачи 2).

правда если уж начали про mysql в качестве nosql, то я бы ожидал услышать про handlersocket, чтобы проходить уже даже и мимо планировщика запросов, а сразу ломиться на получение данных

[samizdam]

Представление это результат определённого SQL запроса.
Запрос к представлению, т.о. запрос к результату другого запроса. Очевидно представления не могут дать прирост производительности, а только наоборот, увеличить нагрузку на БД.

[gibson_dev]

А почему varchar(50) а не char(50)? Как минимум компактнее будет на диске.

[ValdikSS]

Наоборот, varchar имеет разную длину, а char(50) всегда выделяет 50 символов.

[gibson_dev]

Вот в том и дело, данные меньше фрагментированы и на диске меньше места занимают, т.к. в поле varchar еще и длина хранится.

[ValdikSS]

А, они там GUID хранят. Ну да, как-то странно. Но вы правы только конкретно в этом случае.

[zelenin]

и вообще 36 символов, а не 50)

[VolCh]

guid — binary(16)

[skovpen]

А где тесты скорости?

Из документации mysql:

A LEFT [OUTER] JOIN can be faster than an equivalent subquery because the server might be able to optimize it better—a fact that is not specific to MySQL Server alone. Prior to SQL-92, outer joins did not exist, so subqueries were the only way to do certain things. Today, MySQL Server and many other modern database systems offer a wide range of outer join types.

[zapimir]

интересно, а почему

`last_update_date` bigint NOT NULL,

почему не int или timestamp?

[mnv]

Предполагаю, что не int из-за того, что там хранят дату в виде целого числа наподобие 20160523222415 (ГГГГММДДччммсс). Но почему тогда не timestamp — хз. Возможно наткнулись на то, что индекс по timestamp в огромных таблицах не всегда эффективно работает в MySQL.

[Lure_of_Chaos]

Но ведь NoSQL используется не для хранения пар ключ-значение, а именно для хранения неструктурированных данных. А таковые пары — уже определенная структура.
Далее — почему MySQL, а не Postgres, который поддерживает многие типы данных, в т.ч. имеет тип JSON и неплохо работает с ним (не надо хранить блобы)?

Как итог — Вам вообще не нужен NoSQL.

[orthanner]

Используете MySQL в качестве NoSQL-базы — пусть (выше вам объяснили, почему так делать не стоит); но почему при таком раскладе вы не пользуетесь HandlerSocket?!

[youROCK]

Кстати говоря, если вы используете индексы по varchar-полям, и при этом там нет UTF-8, можно поменять сравнение (collation) на, скажем, latin1. Для нашего сервера с логами это позволило увеличить скорость вставки в 5-10 раз (!). Но лучше сначала проверять это предположение с помощью perf top — если видите uca_scanner_next_key или что-то похожее, жрущее 30-40% CPU, то изменение collation поможет :). Это уточнение к предлагаемой структуре для key-value значений.

Кстати говоря, получить десятки и даже сотни тысяч RPS (именно в секунду, а не в минуту, как у wix) вполне реально даже без использования handlersocket. Но с handlersocket многие вещи сильно дешевле по CPU и памяти, особенно коннект.

Вроде как в MySQL 5.7 стоимость коннекта была сильно снижена, так что может быть можно выжать даже большую производительность из одного сервера, если оно зачем-то нужно.

[itcoder]

не используйте внешние ключи

Вы поосторожнее с такими советами, а то люди придут, начитаются, а потом данные у них разъедутся — не делайте так никогда.