Comments 20
> В этой статье мы объясним, почему, по нашему мнению, использовать MySQL для хранения пар ключ-значение лучше, чем большинство специализированных NoSQL-систем
То, что Вы изобрели, ни разу не решает тех проблем, которые заставляют переходить на NoSQL.
То, что Вы изобрели, ни разу не решает тех проблем, которые заставляют переходить на NoSQL.
А вот у меня вопрос, какие основные принципы покрывает NoSql и почему реляционные базы данных уступают?
Я просто смотрю, вы разберитесь, мне просто кажется что при правильной архитектуре того-же postgres нет необходимости в NoSql.
Для меня NoSql это — что-то типа redis ключ-значение, для легкого кеша. Если я ошибаюсь, можно подробный ответ? или ссылки на литературу.
Я просто смотрю, вы разберитесь, мне просто кажется что при правильной архитектуре того-же postgres нет необходимости в NoSql.
Для меня NoSql это — что-то типа redis ключ-значение, для легкого кеша. Если я ошибаюсь, можно подробный ответ? или ссылки на литературу.
Как вы слили все базы в один простой key-value :)
Тынц по базам
Тынц по базам
а теперь главные вопросы которые почему-то остаются за кадром:
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, чтобы проходить уже даже и мимо планировщика запросов, а сразу ломиться на получение данных
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, чтобы проходить уже даже и мимо планировщика запросов, а сразу ломиться на получение данных
UFO just landed and posted this here
А почему varchar(50) а не char(50)? Как минимум компактнее будет на диске.
А где тесты скорости?
Из документации 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.
Из документации 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.
интересно, а почему
почему не int или timestamp?
`last_update_date` bigint NOT NULL,
почему не int или timestamp?
Но ведь NoSQL используется не для хранения пар ключ-значение, а именно для хранения неструктурированных данных. А таковые пары — уже определенная структура.
Далее — почему MySQL, а не Postgres, который поддерживает многие типы данных, в т.ч. имеет тип JSON и неплохо работает с ним (не надо хранить блобы)?
Как итог — Вам вообще не нужен NoSQL.
Далее — почему MySQL, а не Postgres, который поддерживает многие типы данных, в т.ч. имеет тип JSON и неплохо работает с ним (не надо хранить блобы)?
Как итог — Вам вообще не нужен NoSQL.
Используете MySQL в качестве NoSQL-базы — пусть (выше вам объяснили, почему так делать не стоит); но почему при таком раскладе вы не пользуетесь HandlerSocket?!
Кстати говоря, если вы используете индексы по 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 стоимость коннекта была сильно снижена, так что может быть можно выжать даже большую производительность из одного сервера, если оно зачем-то нужно.
Кстати говоря, получить десятки и даже сотни тысяч RPS (именно в секунду, а не в минуту, как у wix) вполне реально даже без использования handlersocket. Но с handlersocket многие вещи сильно дешевле по CPU и памяти, особенно коннект.
Вроде как в MySQL 5.7 стоимость коннекта была сильно снижена, так что может быть можно выжать даже большую производительность из одного сервера, если оно зачем-то нужно.
не используйте внешние ключиВы поосторожнее с такими советами, а то люди придут, начитаются, а потом данные у них разъедутся — не делайте так никогда.
Sign up to leave a comment.
MySQL – это лучшая NoSQL-система