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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

предполагая, что у вас есть python и панды handy 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)

я настоятельно рекомендую попробовать панд с Блокноты Jupyter

Если вы ищете субсекундные результаты запроса OLAP, то Druid (http://druid.io/) был построен для этой цели. Это зверь для развертывания и настройки, но как только вы правильно настроите его для своих данных, это очень быстро. Он имеет потоковую поддержку, так что вы можете глотать из Кафки с точно один раз семантики, которая является удивительным. Он очень хорошо масштабируется от небольших до массивных объемов данных - хотя вы заплатите стоимость, как это делает предварительная агрегация, поэтому, если у вас много измерений размер данных взрывается. Поддержка SQL была добавлена только недавно и является неполной. Также он не поддерживает соединения, поэтому вам нужно правильно структурировать свои данные, чтобы получить ответы.

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