Почему Nosql с Кассандрой вместо MySQL? - PullRequest
11 голосов
/ 04 сентября 2010

Я работаю с большой базой данных (сотни ГБ), и Mysql теперь дает мне более или менее удовлетворение. Я не решаюсь при запуске Кассандры.

Что я хочу знать все раньше, так что такая СУБД NoSQL должна быть быстрее, чем MySQL?

Несколько баллов:

  • Изменение номера столбца в строке В Mysql все они должны быть определены заранее. Колонны установить в структуре таблицы. В NoSQL их можно варьировать. Есть реальная разница производительности на фиксированной структуре? а почему?

  • Не делайте отношения выгодными для производительности. Хорошо, но я не обязан составлять реляционную таблицу Mysql. Я использую агрегированные таблицы, то есть таблицы, которые содержать только данные, полученные из других таблиц, я чтобы предотвратить суставы, которые слишком дороги. Опять какой уровень производительности разница, если я использую эту модель в Mysql? Возьмем один пример, автор http://www.rackspacecloud.com/blog/2010/05/12/cassandra-by-example/ вставьте X количество раз, когда подписчик в сообщении USERLINE pusher. Я мог бы сделать это в MySQL.

  • Масштабируемость, масштабируемость, масштабируемость ... Мне нравится, позволяет ли cassandra хранить мои данные на разных серверах (без SAN)? Я не говорю здесь о репликации, я говорю об одном сервере NoSQL на нескольких физических серверах.

  • Живи по расчетам. MySQL предоставляет такие функции, как я, как SUM, AVG ... которые очень полезны, чтобы избежать повторной агрегации данных в других таблицах. Я не видел эквивалента Кассандра?

  • Как насчет индексов. На Mysql я индексирую несколько полей в одном. Например, у моих таблиц есть первичный ключ в нескольких столбцах, и я выбираю их как функциональные. Кассандра о том, как это написать? Объединенный для одного идентификатора для каждой строки? Я думаю, что я не совсем понял управление индексами. Пересчитаны для интеграции или восходящего потока?

  • Асинхронные запросы. Ложный аргумент, что, как мне кажется, Mysql можно сделать с помощью INSERT / UPDATE LOW_PRIORITY.

Я думаю, что я иду вокруг. Спасибо, что просветили меня.

Ответы [ 3 ]

21 голосов
/ 04 сентября 2010

Я действительно не понимаю, почему люди сравнивают поставщиков данных, таких как Cassandra и MySQL, - вы действительно сравниваете яблоки и апельсины здесь.

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

Для 99% приложений это просто не стоит времени и усилий. Если вы Facebook или Twitter, где у вас огромное количество неструктурированных данных, и вам все равно, потеряете ли вы некоторые данные в случайном порядке или у вас есть задержки с тем, когда данные станут доступны после их вставки, NoSQL это просто хорошо. Однако для подавляющего большинства приложений вы все равно должны придерживаться SQL.

Что касается масштабируемости, если огромный сайт, такой как Stack Overflow или Ebay, может работать поверх SQL, я не понимаю, почему ваше приложение не может работать поверх SQL.

3 голосов
/ 08 сентября 2010

Да, вы определенно можете настроить MySQL, чтобы повысить производительность, сократив множество накладных расходов. NoSQL сокращает накладные расходы, так как не имеет функции, позволяющей включить их в первую очередь.

Приложения NoSQL сильно отличаются от традиционной структуры SQL. SQL по умолчанию настроены на производительность OLTP с нормализованными структурами схемы и возможностью иметь запросы на соединение и т. Д. NoSQL, с другой стороны, является хорошей структурой быстрого чтения / записи. Действительно хорошим примером будет лента активности на твиттере / фейсбуке (я не знаю, использует ли Twitter / FB NoSQL, я просто беру пример).

0 голосов
/ 21 августа 2012

playOrm помогает все большему количеству OLTP-систем войти в число систем noSQL.Это очень похоже на SQL, но есть различия.Вам нужно разделить таблицы, которые вы планируете увеличить до ОЧЕНЬ БОЛЬШИХ размеров, и затем запросить эти разделы.Вы можете даже сделать соединения на разделах.Размеры ваших разделов остаются такими же, как у типичных таблиц СУБД, и вы можете масштабировать их по своему желанию.

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

...