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

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

Предположим, что у меня есть набор данных, который составляет ~ 1M строк. В текущей базе данных, которую мы используем (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. Я ищу альтернативу для наборов данных под строками 10M, где запрос может быть возвращен менее чем за 1 секунду.

Ответ 1

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

Single Redshift small SSD node
- Нет настройки. Легко возвращает ответы на эти данные в течение 1 с.
Greenplum на маленьком экземпляре T2
- Postgres типа. Аналогичный перфоманс для Redshift. Не платя за хранение, вам это не понадобится. Начните с их одиночной node "песочницы" AMI.
Columnstore MariaDB
- MySQL-как. Используется для вызова InfiniDB. Очень хорошая производительность. При поддержке MariaDB (компания).
Сверла Apache
- Drill имеет очень похожую философию BiqQuery, но может использоваться в любом месте (это просто банка). Запросы будут выполняться быстро по данным размера.

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

Ответ 7

Не используйте COUNT(*).

Используйте COUNT() в одном столбце, желательно индексированном, например, PRIMARY KEY.

Ответ 8

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

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

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

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

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

Оптимизация и настройка SQL (таблицы Temp, встроенные функции, OLAP-функции, Sql-план, параллелизация, аналитика) Инструменты (MySql Workbench, cmdline, Toad и т.д.)
Оптимизация структуры (таблицы, индексирование, разбиение на разделы, структуры Pre-Ag)
Конфигурация базы данных (размер памяти, размеры кэша, параллелизация, размер блока и т.д.
Память ОС, размер страницы, Процессы)
Оборудование и сеть - в основном безответственно.
Предоставление сервера.
Предоставление и кластеризация ресурсов.
Решения в области инфраструктуры и программного обеспечения.

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

Ответ 9

Вы не много говорите о пространстве проблем, в котором находитесь, но считаете ли вы python pandas или R? Это отличные инструменты для анализа и разработки данных.

Предполагая, что у вас есть python и pandas удобный pip install pandas, вы можете начать с чего-то вроде этого:

import pandas as pd
import pyodbc

conn = pyodbc.connect(...) # You'll need to figure out the settings for your DB here
# this slow but only needs to be done once:
data = pd.read_sql_query('select * from mytable') # Load everything into memory 

# Now do the query:
data.groupby(['studio', 'territory']).count().sort_values(ascending=False)

Я настоятельно рекомендую попробовать pandas с Jupyter Notebooks

Ответ 10

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