caxapa.ru :: Посоветуйте библиотеку работы с архивами. Чтобы каждые десять секунд писать пятьсот параметров и хранить десять лет. Способную из этого bigdata за одну минуту выхватить суточный интервал трех-четырех параметров трех последних лет

Скрипач^пророк (09.07.2019 17:23, просмотров: 42551)

Посоветуйте библиотеку работы с архивами. Чтобы каждые десять секунд писать пятьсот параметров и хранить десять лет. Способную из этого bigdata за одну минуту выхватить суточный интервал трех-четырех параметров трех последних лет и выдать под отрисовку.

... но не любой ценой.

Ответить

- Единственное, что я видел подобное было коммерческим и проприетарным bodis(147 знак., 12.07.2019 22:34, ссылка)
  - Для простых смертных есть RRDtool. Но он именно нас не устраивает некоторыми второстепенными деталями реализации. Скрипач(112 знак., 12.07.2019 22:39)
- MQTT => Хаос(36 знак., 12.07.2019 10:48, )
  - MQTT не хранит историю по тегам. - Скрипач(12.07.2019 10:53)
- Berkeley DB. - fk0(10.07.2019 00:07, ссылка)
  - +1. Используется в Bitcoin Core, а у Биткойна размер базы за 200ГБ перевалил, вроде. - Nikolay_Po(10.07.2019 08:03)
- Сначала прописывают последовательность действий при доступе к БД, включая оценку объёмов информации по запросу и их количество, а потом уже выбирают технологию. И да, классические сервера со SCSI / SAS HDD изначально не быстрые, приходится De_User(139 знак., 09.07.2019 21:38 - 21:48)
- датавремя - имя тега - значение. Если сразу сделать составной ключ на (датавремя, имя тега), то доп. индекс не понадобится, т.к. создастся кластерный индекс и на диск будет писаться уже в сортированном виде. Искать быстро будет когда при выборке в Ан(363 знак., 09.07.2019 21:33, )
- "дата Ан(611 знак., 09.07.2019 21:29, )
- посмотри как это сделали сегнетики в свежей версии. они это назвали смхистори. - LordN(09.07.2019 20:53)
  - Не уверен что его можно "оторвать". Оно ж под работу на их контроллере заточено, нет? - Скрипач(09.07.2019 20:56 - 21:03)
    - ну там линух, а что в линухе можно увидеть а чего нельзя я хз.. LordN(33 знак., 10.07.2019 13:14)
- Сколько записей-то в итоге? У меня в базе из примерно 10 млн. записей нужные значения вытаскиваются по дате за секунду. Архив за 3 года. База данных SQL Server. Никаких индексов нет. - FDA(09.07.2019 20:04)
  - Это чиста побочный эффект - когда руки растут из правильного места и круглое с ушами думать мала мала умеет :) - De_User(10.07.2019 17:36)
    - небось и "перемотка" в середину 25 ГБ BDRip фильма 2160p @60Hz менее, чем за 1 с. происходит? - De_User(10.07.2019 18:59)
  - Сейчас чуть меньше 25млн.записей. Еще год не прошел. Нужно работать с объемом в десять раз больше. - Скрипач(09.07.2019 21:22)
- ИМХО это все ж в сторону базы данных надо смотреть мне кажется... обьем данных то за 10 лет получится под 50-100 гигов - sav6622(09.07.2019 17:31)
  - Один SSD на 120 Gb или 240 Gb - De_User(09.07.2019 20:45)
    - Да ну нафиг, лучше в облако... все грохнется в один момент... - sav6622(09.07.2019 20:52)
      - У меня два HDD в аппаратном RAID. И раз в неделю бакап... куда-то в недра корпоративной IT заказчика. - Скрипач(09.07.2019 20:55)
        
        Это безусловно хорошо, но недешево... Еще бы проверить что из бекапа можно восстановиться... и что рейд при потере одно винта будет работоспобен... sav6622(95 знак., 09.07.2019 21:16)
        
        С этого и нужно начинать. Или серверный контроллер + серверные HDD или SSD NMVe типа Intel Optane SSD 900P или Samsung 960 EVO, ежедневно (сжатая) копия на HDD, еженедельная "куда нужно". - De_User(09.07.2019 21:03 - 21:08, ссылка, ссылка)
        
        Взрослый сервер НР. Я отказываюсь оптимизировать железо, его явно должно быть достаточно, при правильном подходе. Скрипач(125 знак., 09.07.2019 21:07)
        
        Согласен, вмешиваться в аппаратуру сервера занятие неблагодарное. Зато ПО сервера ещё уметь настраивать нужно, начиная с установки достаточного (для задачи) объёма ОЗУ. И механизм доступа без "посредника" заведомо самый медленный. - De_User(09.07.2019 21:12 - 21:25, ссылка)
- Их есть у нас! -> - Evgeny_CD(09.07.2019 17:31, ссылка)
  - Не в этом смысле. Десять терабайт есть где положить. Хоть в SQL, хоть в plain text-e. А вот взять "что было в этот день, но год, два и три назад" - реально дикий тормоз. Нужно как-то правильно кэшировать. Скрипач(38 знак., 09.07.2019 17:34)
    - А в чем проблема использовать, собственно говоря, SQL? Хоть SQLite, он до 140 терабайт тянет. lloyd(46 знак., 09.07.2019 17:49)
      - Мы недавно пробовали приладить SQLite к одной из своих задач и он, похоже, жуткий тормоз. - AlexG(10.07.2019 05:44)
        
        Небось fsync=2 и пихали строчки по-одной? - lloyd(10.07.2019 09:00)
        
        Именно так. А как надо было? - AlexG(10.07.2019 10:23)
        
        Хотя бы упаковывать десятки-сотни строк в транзакции. - lloyd(10.07.2019 11:42)
    - припоминается долгая процедура индексирования, после которой поиск становится быстрее - Vit(09.07.2019 17:44)
      - Да, по факту, не быстро. 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, ссылка)

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