Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / MySQL [игнор отключен] [закрыт для гостей] / хранение, поиск и выдача по таблице с более 10 мрлн записей / 25 сообщений из 31, страница 1 из 2
  1  все
30.05.2018, 17:37
    #39652726
chiffacff
chiffacff
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
Всем привет. Собственно сабж. планируется таблица с количество записей более 10 миллиардов, приблизительной структуры:

Поле1 - user_id - int(11) - key
Поле2 - shop_id - int(3) - key
Поле3 - start_day - datetime
Поле4 - end_day - datetime
Поле5 - start_price - decimal
Поле6 - end_price - decimal
Поле7 - id - bigint - unique

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

При запросе данные будет идти поиск по полям Поле1, Поле2, Поле1+Поле2. Ориентировная нагрузка при select 1300-1500 в минуту.


Несколько вопрос:
1. Насколько правильно использовать для описанной задачи MySQL (а точнее MariaDB) либо же лучше другую базу?
2. Клиент, на основе полученных данных будет строить график, поэтому выдача, скорее всего, будет идти частями через web-socket, что бы не тормозить отображение, насколько правильно будет использование LIMIT?
3. насколько правильно будет делать order by id desc для сортировки выдачи?
4. Насколько я понимаю, механизм кеширования необходимо реализовывать на стороне бэка т.к. частый инсерт сводит кеширования средствами mysql к нулю

буду признателен за помощь и советы! Заранее спасибо!
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.05.2018, 18:04
    #39652751
вадя
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
chiffacff,
у тебя диски не выдержат.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.05.2018, 18:24
    #39652766
chiffacff
chiffacff
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
вадя,

и какие варианты решения?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.05.2018, 18:52
    #39652783
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
chiffacffПоле1 - user_id - int(11) - key
Поле2 - shop_id - int(3) - key
Поле3 - start_day - datetime
Поле4 - end_day - datetime
Поле5 - start_price - decimal
Поле6 - end_price - decimal
Поле7 - id - bigint - unique2*int+2*datetime+2*decimal+1*bigint = 2*4+2*8+2*6+8=44 байта плюс-минус на запись. При 10ккк записей, да плюс индексы и т.п. - это под терабайт. Я бы не советовал даже думать про MySQL на таких объёмах в рамках одного сервера...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 06:19
    #39652974
982183
982183
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
chiffacffДанные будут вставляться периодично, раз в минуту.
Планируемый объем вставляемых ежеминутно данных (строк) +/-
Круглосуточно или есть перерывы?

chiffacffОриентировная нагрузка при select 1300-1500 в минуту.
1300-1500 чего?

chiffacff2. Клиент, на основе полученных данных будет строить график,
Он же график будет строить не в 10 миллиардов точек?
Всё равно данные будет каким-то образом агрегироваться (день/месяц)?.
Может имеет смысл делать выборку с некой промежуточной агрегированной таблицы?
Насколько актуальным должен быть график? Достаточно ли данных по вчера?

Как много он будет строить графиков в день?
Каковы пожелания/ограничения на скорость "построения"?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 06:22
    #39652975
982183
982183
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
В каком виде и где сейчас эта таблица с имеющимися данными?
Каков её физический объем?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 08:46
    #39653009
tip78
tip78
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
ху*ня получится. Тут надо актуальные данные в отдельной таблице держать, чтобы маленькой была, агрегацию по возможности, по годам может разбить, и прочие варианты уменьшения объёма.
одним кешированием тут не обойтись ))

chiffacffПри запросе данные будет идти поиск по полям Поле1, Поле2, Поле1+Поле2
это 1 сводный индекс
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 09:17
    #39653030
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
tip78это 1 сводный индексНе, два... один по (Поле1, Поле2) и второй по (Поле2).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 12:47
    #39653192
chiffacff
chiffacff
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
982183Планируемый объем вставляемых ежеминутно данных (строк) +/-
Круглосуточно или есть перерывы?

круглосуточно

9821831300-1500 чего?

запросов по поиску в таблице и выдачи данных



982183Он же график будет строить не в 10 миллиардов точек?
Всё равно данные будет каким-то образом агрегироваться (день/месяц)?.
Может имеет смысл делать выборку с некой промежуточной агрегированной таблицы?
Насколько актуальным должен быть график? Достаточно ли данных по вчера?

Как много он будет строить графиков в день?
Каковы пожелания/ограничения на скорость "построения"?

да, будут периоды. минута, час, 2 часа .... день месяц и т.д.


982183В каком виде и где сейчас эта таблица с имеющимися данными?
Каков её физический объем?

пока еще разработка, еще таблицы нету
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 13:05
    #39653215
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
chiffacffбудут периоды. минута, час, 2 часа .... день месяц и т.д.Ну в принципе партиционирование по дате (ну или там по месяцу) более-менее может снять остроту проблемы при небольших по времени выборках. Но несильно...
Чисто в теории всё одно для вменяемой скорости на таких объёмах надо делать предрасчёты статистики.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 13:37
    #39653244
chiffacff
chiffacff
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
расчетов не будет. толко хранение и вывод
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 13:45
    #39653254
Akina
Akina
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
Вывод за месяц - это какой объём-то, Вы считали? а то счас выясните что горите желанием вывалить с сервера на клиента полтора гига хламу...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 13:58
    #39653279
tip78
tip78
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
Akinatip78это 1 сводный индексНе, два... один по (Поле1, Поле2) и второй по (Поле2).
это если нужны будут все юзеры в шопе

chiffacff982183В каком виде и где сейчас эта таблица с имеющимися данными?
Каков её физический объем?
пока еще разработка, еще таблицы нету
напомнило один "стартап", который хотел порвать все социалки. Взяли серверов кучу, гигабиты на каждом, ssd диски, везде я все настроил и оптимизировал подсистемы. В результате спустя год простоя, даже без минимальной нагрузки, инвестор прекратил финансирование, а разработчики были разогнаны...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 14:07
    #39653284
tip78
tip78
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
tip78это если нужны будут все юзеры в шопе
кстати, вопрос про потроха - ежели соотношение не в общей таблице, а в НФ, то поиск же быстрее должен работать?
там всё-таки размер поменьше...
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 15:22
    #39653372
Arm79
Arm79
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
chiffacffПри запросе данные будет идти поиск по полям Поле1, Поле2, Поле1+Поле2
У вас будут запросы типа shopId + userId?
Если по отдельности каждое поле, то мне кажется, от индексов на них не будет никакого толку.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 15:50
    #39653407
chiffacff
chiffacff
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
tip78кстати, вопрос про потроха - ежели соотношение не в общей таблице, а в НФ, то поиск же быстрее должен работать?

НФ это что?...

Arm79 У вас будут запросы типа shopId + userId?
Если по отдельности каждое поле, то мне кажется, от индексов на них не будет никакого толку.
в 80% случаях и по тому и по тому
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 16:08
    #39653418
tip78
tip78
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
Нормальная Форма 1
таблица, где только: user_id | shop_id
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 16:18
    #39653422
982183
982183
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
Планируемый объем вставляемых ежеминутно данных (строк) +/-

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

А там или шах, или ишак, или Насреддин сдохнет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 16:41
    #39653438
chiffacff
chiffacff
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
982183Планируемый объем вставляемых ежеминутно данных (строк) +/-
порядка 1 828 800 записей в сутки
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 17:12
    #39653459
вадя
вадя
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
chiffacff,

это ж что такое пишется?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 19:19
    #39653558
chiffacff
chiffacff
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
статистика, данные, история
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
31.05.2018, 19:28
    #39653563
tip78
tip78
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
если там логи или ещё какая отчётность, то просто делайте агрегацию (кроном или демоном) раз в 1/5/60 минут и не парьтесь
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.06.2018, 03:21
    #39653649
982183
982183
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
2 млн записей в день это конечно с одной стороны серьезно, а с другой стороны явно не юзеры будут это вводить.
Надо разделить таблицу хранения первичных данных и таблицу из которой берутся данные для отчетности.
Которая будет и агрегированна и адаптирована.
Всё зависит от специфики твоей отчетности
1300-1500 запросов в минуту это вряд ли.
Есть только у тебя не под тыщу получателей, что маловероятно.
Тут явно нужен анализ и оптимизация отчетности.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.06.2018, 03:26
    #39653650
miksoft
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
982183таблицу хранения первичных данныхЯ бы предложил первичные данные вообще не писать в БД. А только сохранять в лог-файл, чтобы при необходимости пересчитать какой-то из агрегатов.

Ну или писать, но очень немного - порядка минимальной порции агрегации.

А вообще существуют специальные СУБД для хранения временных рядов (time series database).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.06.2018, 03:29
    #39653651
982183
982183
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
хранение, поиск и выдача по таблице с более 10 мрлн записей
chiffacff982183Планируемый объем вставляемых ежеминутно данных (строк) +/-
порядка 1 828 800 записей в сутки
1 828 800 *365 = 667 512 000 в год
Вполне реальная цифра.
И реальная возможность в первый/первые год/ы эксплуатации отладить систему и после этого готовиться к работе и проблемам бигдаты.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / MySQL [игнор отключен] [закрыт для гостей] / хранение, поиск и выдача по таблице с более 10 мрлн записей / 25 сообщений из 31, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]