caxapa.ru :: припоминается долгая процедура индексирования, после которой поиск становится быстрее

Vit (09.07.2019 17:44, просмотров: 530) ответил Скрипач на Не в этом смысле. Десять терабайт есть где положить. Хоть в SQL, хоть в plain text-e. А вот взять "что было в этот день, но год, два и три назад" - реально дикий тормоз. Нужно как-то правильно кэшировать.

припоминается долгая процедура индексирования, после которой поиск становится быстрее

Ответить

- Да, по факту, не быстро. PostgreSQL. Даже в пределах одного года больше десяти минут ворочается. - Скрипач(09.07.2019 18:00)
  - А индекс вы создавали? -_- - lloyd(09.07.2019 18:03)
    - Сейчас все лежит в одной таблице "дата/время - имя тега - значение". Индекс по дате/времени. - Скрипач(09.07.2019 18:07)
      - Key поле этой таблицы сделать из даты, типа: 201907122145. То есть ГодМесяцЧислоЧасовМинутСекунд. И будет всё очень быстро. - бомж(09.07.2019 19:30 - 19:34)
        
        Под "ГодМесяцЧислоЧасовМинутСекунд" это есть специальный тип поля "timestamp" с компактным внутренним кодированием, поэтому индексируется заметно быстрее. - De_User(09.07.2019 21:16)
        
        Этот тип поля сейчас и применен. Но он не годится для primary key. Есть идея сконструировать специальный тип для primary key. - Скрипач(09.07.2019 21:25)
        
        Наличие Primary Key требуется для корректной работы большинства СУБД, и также в большинстве случаев он не имеет никакого отношения к структуре, назначению и применению данных. Primary Key, он же уникальный номер записи, просто "должен быть". De_User(90 знак., 09.07.2019 22:45 - 22:49)
        
        Стоит :) Мне нужно быстрее. Я знаю что физически это возможно. Осталось убедить в этом СУБД :) - Скрипач(09.07.2019 22:51)
        
        Учиться, учиться и учиться :) Чем дальше, тем проще будет проектировать и "быстрее" будет получаться само собой. В технологиях СУБД очень много полезного и удобного предусмотрено, используйте на здоровье :) - De_User(09.07.2019 22:56)
        
        Спасибо, попробую. С виду почти так и сделано, но видимо "есть нюанс". - Скрипач(09.07.2019 19:34)
        
        Вообще чем короче ключ, тем быстрее поиск. Вроде бы это очевидно. - s_h_e(09.07.2019 19:50)
        
        Нет, на больших таблицах это не всегда так. Если надо делать запрос типа: SELECT * FROM MyTable m WHERE m.ID >= 20190101000000 AND m.ID < 20190102000000 - бомж(09.07.2019 20:01)
        
        +1 - De_User(09.07.2019 20:34)
      - Ок, следующий вопрос: вы все эти 157 миллионов записей разом запрашиваете из базы, или все же бежите курсором? Пробовали профилировать запрос, на что тратится бОльшая часть времени? Мб просто на перегонку/переформатирование данных? - lloyd(09.07.2019 18:19)
        
        Запрашиваю несколькими SQL-запросами, с ограничением по диапазону дат и именем тега, по одному на запрос (точнее ORM для меня запрашивает). Глубоко не копал, не профилировал. Где почитать как и чем профилировать? - Скрипач(09.07.2019 18:50)
        
        Вот имя тэга запросто может тормозить, если это поле не индексировано. Лучше запросить только выборку по дате, а отсортировать по тэгу уже на локальном компьютере. Либо перед запросом строить индекс по нужному полю тэга. - бомж(09.07.2019 20:14)
        
        Лучше вспомнить про нормальные формы и разбить на две таблицы. Чтоб вместо имени тэга был ключ из таблицы с тэгами. Сравнивать по крайней мере будет числа, а не строки, при поиске. - fk0(10.07.2019 00:28)
        
        @#я! Если при разработке изначально не знать и не применять нормализацию (там, где это целесообразно), то результат - лотерея. В лучшем случае. - De_User(10.07.2019 01:11 - 01:16)
        
        Это поле тоже индексировано. Тонкое место в том, что и поле тега и дата-время не primary key (ибо не уникальны). Скрипач(186 знак., 09.07.2019 20:20)
        
        Индексов на датувремя и тег два? Или один составной? Если два, то есть вероятнось, что sql использует индекс по тегу, а надо наоборот. Если два индекса я бы их удалил и сделал один составной или удалил индекс на тег. Тегов около 500 особо выигрыша Ан(36 знак., 10.07.2019 11:08, )
        
        Уникальность не обязательна, мало на что влияет. Быстрее всего сделать запрос SQL для выборки данных во вспомогательную БД (например, по дате) и уже в ней "копаться" по второму и т.д. условиям. - De_User(09.07.2019 20:42)
        
        Сомнительно. Но нужно проверить. Всю дорогу считал что если все требования "помещаются" в один SQL-запрос, то это и есть самый быстрый способ. Скрипач(97 знак., 09.07.2019 20:49 - 20:57)
        
        То что я подсказал, применяют на очень серьёзных фирмах и очень ответственных базах данных. Это типовое решение. Ну и можно запрос с выборкой по двум критериям в хранимые процедуры засунуть. - бомж(09.07.2019 20:22 - 20:30)
        
        До трети запросов - с того же комьютера где лежит база. По ощущениям разницы времени обработки между локальным АРМ и удалённым нет никакой. Скрипач(114 знак., 09.07.2019 20:29)
        
        А покажите запросы к таблице, если не тайна - бомж(09.07.2019 20:31)
        
        Не тайна, но это запросы к ORM. Из них еще нужно подумать как SQL получить. - Скрипач(09.07.2019 20:33)
- Ничто не так не ускоряет базу данных, как правильная настройка ее архитектуры и параметров при создании БД! И не факт, что SQL в данном случае нужон. noSQL -> вполне взрослое направления для специализированных баз данных, и для данных определенной Evgeny_CD(71 знак., 09.07.2019 17:59, ссылка)
  - У вас есть какая-то конкретная мысль или вы о категории noSQL как таковой? (в данном случае noSQL не кажется применимым) - Скрипач(09.07.2019 18:52)
    - Если вкратце, то при выборе Btree в качестве метода хранения появляется возможность поиска по частичному ключу в сортированных данных. Т.е. курсор автомагически ставится на начало диапазона, с ключём большим или равным заданному (см. fk0(511 знак., 10.07.2019 00:47, ссылка)

Средства и методы разработки