Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
Задача: быстро проводить поиск наличия записи (номер телефона) в огромном массиве данных (десятки миллионов строк). Возникла мысль - на этапе загрузки данных в базу создавать таблицы, имя которых основано на первых 3-х или 4-х цифрах номера, и соответственно размещать данные в нужных таблицах: номер 79001234567 помещаем в таблицу 9001, а 79281234567 в таблицу 9281. Соответственно, при поиске данных (важно определить сам факт наличия записи в базе) мы будем искать данные сразу в нужной таблице, которая естественно намного меньше по объёму, чем все данные. Поиск будет в несколько десятков потоков через php, номера рандомные, соответственно запросы могут быть одновременно к нескольким таблицам. Поможет ли такой подход увеличить быстродействие? На какие ещё нюансы обратить внимание? Спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 01:56 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
whoimВозникла мысль - на этапе загрузки данных в базу создавать таблицы, имя которых основано на первых 3-х или 4-х цифрах номера, и соответственно размещать данные в нужных таблицах: номер 79001234567 помещаем в таблицу 9001, а 79281234567 в таблицу 9281.Поздравляю, Вы изобрели партиционирование. whoimНа какие ещё нюансы обратить внимание? А идея создать индекс в голову не приходила? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 08:18 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
А индекс поможет при сотне миллионов строк? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 08:19 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
Нет, блин, индексы придуманы исключительно для того, чтобы на винтах свободное место не простаивало! Ну что за детский сад-то, право слово? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 08:22 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
Вы, наверное, меня не поняли) Естественно, что индексы будут использоваться. Можно ли обойтись одним индексом, без разбиения на таблицы? Или, учитывая объёмы, лучше все таки разбивать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 11:22 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
Десятки миллионов записей - это объём приличный, но вовсе даже не огромный. Индекс по номеру телефона будет байт 20 на запись, т.е. индекс метров 200. Поиск в таком индексе будет достаточно быстрым. Просто надо понимать, что для снижения времени поиска вдвое даже чисто теоретически надо будет сделать порядка сотни партиций - а на самом деле выигрыш окажется гораздо меньше желаемого... Что же до раскладывания данных в несвязанные таблицы - не советую даже задумываться о таком подходе. Явно не тот случай по соотношению профита к геморрою. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 11:37 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
Спасибо! Думаю, дальше будет правильным потестировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 11:38 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
Если уж на то пошло, то при отсутствии неформатов в поле номера телефона разумнее преобразовать его в целочисленный тип (BIGINT). Тут, пожалуй, можно поиметь какой-то профит - если нет регулярной задачи поиска номера по шаблону типа '7916123??45' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 11:41 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
AkinaЕсли уж на то пошло, то при отсутствии неформатов в поле номера телефона разумнее преобразовать его в целочисленный тип (BIGINT). Тут, пожалуй, можно поиметь какой-то профит - если нет регулярной задачи поиска номера по шаблону типа '7916123??45' А в чем проблема при поиске по шаблону в том случае? >79161230045 && <79161239945 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 12:12 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
БигИнт и планировался, искать надо точное вхождение точного номера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 12:17 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
PolarА в чем проблема при поиске по шаблону в том случае?В конкретно том - никакой. Кроме преобразования маски в диапазон. Но ведь маска может быть, например, '791?123??45' - и станет грустно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 12:26 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
AkinaPolarА в чем проблема при поиске по шаблону в том случае?В конкретно том - никакой. Кроме преобразования маски в диапазон. Но ведь маска может быть, например, '791?123??45' - и станет грустно. ну в 10 раз больше условий будет. Я бы первую цифру выкинул из базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 12:45 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
PolarЯ бы первую цифру выкинул из базы.Где гарантия, что в БД не будут попадать забугорные номера? да и не мешает она в общем-то... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 13:48 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
Делается сразу под любые номера, кроме конечно имеющих ведущий ноль. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 14:48 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
whoimДелается сразу под любые номера, кроме конечно имеющих ведущий ноль.Проходили. Не я - знакомые. Они просто заменили ведущий плюс на единицу, и при обработке добавляли её в фильтр и убирали перед выводом. Ну и для "наших" номеров заменяли ведущую "8" на "+7" единого образия ради. Неплохо вроде работало... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 18:03 |
|
||
|
Выиграю ли я в скорости select, применив динамическое использование страниц?
|
|||
|---|---|---|---|
|
#18+
AkinaГде гарантия, что в БД не будут попадать забугорные номера? да и не мешает она в общем-то... Убрать тогда в другое поле. Забугорные номера бывают двузначные. Это все таки код страны, отличается по смыслу от всех остальных циферок в номере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2017, 20:50 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39445980&tid=1830716]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
148ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 11ms |
| total: | 249ms |

| 0 / 0 |
