mysql - omit - legacy sql




Альтернатива BigQuery для данных среднего размера (8)

Это продолжение вопроса « Почему BigQuery не работает так же хорошо для небольших наборов данных» .

Предположим, у меня есть набор данных, который составляет ~ 1 млн строк. В текущей базе данных, которую мы используем (mysql), запросы агрегации будут выполняться довольно медленно, возможно, на ~ 10 с или около того на сложных агрегациях. В BigQuery требуемое время инициализации может заставить этот запрос занимать ~ 3 секунды, что лучше, чем в MySQL, но не подходит для работы, если нам нужно возвращать запросы в 1 с или ниже.

Тогда у меня возникает вопрос: что может быть хорошей альтернативой использованию BigQuery при выполнении агрегированных запросов к наборам данных среднего размера, таким как строки 1-10M? Пример запроса может быть:

SELECT studio, territory, count(*)
FROM mytable
GROUP BY studio, territory
ORDER BY count(*) DESC

Возможные решения, о которых я подумал, - это ElasticSearch ( https://github.com/NLPchina/elasticsearch-sql ) и Redshift (postgres работает слишком медленно). Что было бы хорошим вариантом здесь, который может быть запрошен через SQL?

Примечание: я не ищу, почему или как следует использовать BQ, я ищу альтернативу для наборов данных длиной менее 10 миллионов строк, где запрос может быть возвращен менее чем за ~ 1 с.


BigQuery предназначен для наилучшей работы в конце конвейера Big Data. Он был спроектирован так, чтобы хорошо работать с большими наборами данных, а не с небольшими, и не предназначен для замены существующих технологий, а скорее как отличное дополнение в определенных ситуациях. Пример можно прочитать в document «Блог о больших данных и машинном обучении Google Cloud».


Вот несколько альтернатив для данных такого размера:

  1. Одиночный Redshift маленький SSD узел
    • Нет настройки. Легко возвращает ответы на это много данных в возрасте до 1 с.
  2. Greenplum на маленьком экземпляре T2
    • Postgres-как. Подобный перф к Redshift. Не платить за хранение вам не понадобится. Начните с их единого узла «песочница» AMI.
  3. MariaDB Columnstore
    • MySQL как. Раньше назывался InfiniDB. Очень хорошая производительность. При поддержке MariaDB (компания).
  4. Apache Drill
    • Drill имеет очень похожую философию с BiqQuery, но может использоваться где угодно (это просто баночка). Запросы будут быстро на этот размер данных.

Если низкий админ / быстрый запуск критичны, используйте Redshift. Если деньги / гибкость имеют решающее значение, начните с Drill. Если вы предпочитаете MySQL, начните с MariaDB Columnstore.


Если вам не нужен параллелизм, одновременное подключение нескольких пользователей и ваши данные могут поместиться в один файл на диске, тогда SQLite может подойти.

Как говорится, SQLite не конкурирует с базами данных клиент / сервер. SQLite конкурирует с fopen ().

http://www.sqlite.org/whentouse.html


Если вам нужны ответы менее чем за секунду, вам нужно подумать об индексации.

Типичная история:

  1. MySQL (или любая другая предлагаемая здесь база данных) работает быстро, пока ...
  2. Однажды некоторые из ваших запросов агрегации начинают работать медленно. Минуты, часы, дни и т. Д.
  3. Типичным решением для шага 2 является индексация и предварительная агрегация. Если вы хотите получить ответы менее чем за секунду для вопросов определенного типа, вам нужно потратить время и циклы оптимизации, чтобы ответить именно на этот тип вопросов.
  4. Прелесть BigQuery в том, что вы можете пропустить шаг 3. Приведите эти минуты / часы / дни к секундам с минимальными затратами - любой запрос в любое время.

BigQuery потрясающий, потому что он дает вам 4. Но вы просите 3, MySQL подходит для этого, Elasticsearch также хорош, любая индексированная база данных даст вам результаты менее чем за секунду - если вы потратите время на оптимизацию вашей системы для определенного типа вопроса. Затем, чтобы получить ответы на любой произвольный вопрос, не тратя время на оптимизацию, используйте BigQuery.

BigQuery: ответит на произвольные вопросы в считанные секунды, без подготовки.

MySQL и альтернативы: ответит на некоторые вопросы менее чем за секунду, но для этого потребуется время на разработку.


Если это ваш единственный запрос, то он будет выполняться быстрее:

INDEX(studio, territory)  -- in either order.

Если есть другие варианты, давайте посмотрим их, а также SHOW CREATE TABLE .

Еще одна вещь, которую нужно проверить: сколько у вас оперативной памяти и каково значение innodb_buffer_pool_size ? Этот параметр должен составлять около 70% ОЗУ (если у вас более 4 ГБ ОЗУ).


Мой ответ: Оптимизируйте структуру запроса и таблицы в соответствии с ранее адресованными (1 секунда или меньше). Читайте ниже для дальнейшего рассуждения, потому что мы все попадаем в эту ловушку. Примечание: выше не обязательно большой набор данных.

Отличный вопрос. Это такая борьба, чтобы понять, в чем проблема и что является решением. Вот выстрел из старой школы. В старые времена мы говорили, что вы спрашиваете аппаратное обеспечение, ОС или разработчика, в чем заключается проблема / решение, и вы получите три разных ответа.

Насколько я понимаю, этот вопрос просит решить / сравнить проблему производительности SQL с решением облачной инфраструктуры. Этот вопрос будет иметь много разных ответов на основе фона. Это сбивает с толку, у вас есть только старые установки баз данных (Mysql, Oracle, MSsql), база данных как услуга (DBAAS), решения для больших данных, решения для больших данных (hadoop)

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

Проблемы производительности SQL могут быть решены в различных точках производительности (POP).

  1. Инструменты оптимизации и настройки SQL (временные таблицы, встроенная память, функции OLAP, план Sql, распараллеливание, аналитика) инструменты (MySql Workbench, cmdline, Toad и т. Д.)
  2. Оптимизация структуры (таблицы, индексация, разбиение, структуры Pre-Ag)
  3. Конфигурация базы данных (размер памяти, размеры кэша, распараллеливание, размер блока и т. Д.
  4. Оперативная память, размер страницы, процессы)
  5. Аппаратное обеспечение и сеть - в основном бездействующие сейчас.
  6. Подготовка сервера.
  7. Облачная подготовка и кластеризация.
  8. Инфраструктурные и программные решения.

Итог: я остановлюсь здесь, у нас так много решений проблем. Постарайтесь начать с самого простого использования технологии, прежде чем нести расходы решения с более крупными технологиями. Надеемся, что это даст пользователю скелет пути проработки или терминологии, которую следует использовать при задании вопроса. Как я могу получить запрос x для запуска в момент времени t?


Я думаю, что Microsoft SQL Server Analysis Services - хороший вариант, я использовал его сам, это база данных, стоящая за сервисом PowerBI, которая имеет очень хороший вариант бесплатного уровня.

если вам нужно бесплатное решение для использования в помещении, вы всегда можете использовать SQL Server Express с новой технологией columnstore, я сам его не использовал, но слышал некоторые очень хорошие результаты


Я знаю SQL Server, поэтому мой ответ предвзят.

  1. 10M строк должны легко помещаться в памяти, поэтому любой тип агрегации должен быть быстрым, особенно если у вас есть индекс покрытия. Если этого не произойдет, может потребоваться настройка конфигурации сервера. Кроме того, SQL Server имеет так называемые таблицы в памяти , которые могут здесь хорошо подойти.

  2. SQL Server имеет функцию под названием индексированное представление . Ваш агрегирующий запрос является классическим вариантом использования индексированного представления. Индексированное представление - это, по сути, копия данных, хранящихся на диске и автоматически поддерживаемых сервером при изменении базовых данных в таблице. Это замедляет INSERTS, DELETES и UPDATES, но делает SELECT быстрым, потому что сводка всегда рассчитывается заранее. Смотрите: что вы можете (и не можете) делать с индексированными представлениями . Другие СУБД должны иметь аналогичные функции.





amazon-redshift