• XSS.stack #1 – первый литературный журнал от юзеров форума

TXT BigData и быстрый поиск: эффективная работа с данными

Отслеживать

Igrmr

(L3) cache
Пользователь
Регистрация
09.11.2020
Сообщения
214
Реакции
119
Коллеги, по мере того как растет обьем данных на диске возникает вопрос поиска и его скорости в этом массиве данных, состоящем из большого количества разных по структуре и размеру файлов

Поиск через обычные grep, ack, ag или rg занимает кучу времени и, соответственно, возникает вопрос индексирования. Пробовал elasticsearch (не устроила скорость заливки данных и форматирования входящих данных, даже с учетом фильтров logstash), mongodb (заливка json происходит более быстро, но скорость все равно не устраивает). Пробовал свой вариант индексации через приведение к единому формату и общему первому полю, с последующим разбитием на папки/файлы по индексам 0-9, a-z (аналогично тому, что сделано в Breach Compilation). Такой подход позволил получить серьезный прирост в скорости поиска, но по мере увеличения размера базы эффективность существенно снижается.

Соответственно вопрос: как лучше всего своими силами, локально, организовать работу и быстрый поиск в большом массиве данных, хотя бы по первому полю, после приведения к единому формату?
 
Всё зависит от технического задания, планов и целей использования. Именно под это и подбирается СУБД, если это веб-проект, в котором есть определенные лимиты данных, то наверное не на первом месте стоит какую именно СУБД выбрать. Если мы говорим о BigData в классическом смысле, если идет просчет скорости, масштабирования, т.н. правило трех "V" (velocity, volume, variety) то для этого однозначно понадобится NoSQL СУБД, такая как HBase, естественно и файловая система для этого понадобится другая, например HDFS. Но, нынче под биг-датой принято подразумевать что угодно, накачал человек всяких баз данных, забил диски, для него это биг-дата ))
Если вам нужно просто абы быстрее чехлило поиск, конечно вам понадобятся индексы, это может быть "dtSearch", или какой-нибудь "Архивариус 3000". Я не пользуюсь ни тем, ни другим, когда пользовался, там не было поддержки регулярных выражений. Что собственно и делало малополезным использования такого софта под мои задачи. Возможно это уже и реализовали, если да, то я смотрел бы в сторону решения, которое поддерживает регулярки.
Если взять для примера коллекцию Breach, в которой идут строки, мыло и пасс разделены условным разделителем, двоеточием кажется, то чисто для поиска не суть важно, структурировать ли это в некую СУБД, или накатить индексы для быстрого поиска по исходникам текстовиков. На первый взгляд, тем не менее разница будет проявляться, в зависимости от объема данных. Потому что поиск по структурированным данным быстрее, чем по строке с использованием языка запросов, например, регулярок. Ну к примеру нам нужно отобрать значения поисковые только в пароле, или только в почте. На больших объемах вы поймете в чем разница. Ко всему прочему сам поиск, его условия, полнотекстовый, или точного вхождения это разные вычислительные нагрузки, которые и будут видны по времени их выполнения.
Я не знаю что вам посоветовать, главным образом потому что не понял что вам нужно. Поскорее машину раздобыть что бы побыстрее ехать, или машину которая будет и ездить быстрее и с увеличением перевозимого ею груза скорость ее не будет снижаться. Это разные вещи.
 
Речь идет о поиске (в идеале, с использованием wildcard, по первой колонке, которая для всех файлов однообразна) среди файлов на внешнем hdd средствами Linux без привязки к машине. Понятно, что оптимальным решением было бы NoSQL СУБД, но тут возникают ранее описанные проблемы + привязка к конкретной машине или конкретной СУБД. Elastic или mongo на VPS и заливка туда данных не рассматриваются. Что касается, Breach Compilation, то там не только однообразный формат и разделение данных черех двоеточие на мыло и пасс, но также и разделение данных по отдельным папкам и файлам в зависимости от первых букв строки, что позволяет ускорить поиск через специальный скрипт.
 
Igrmr сказал(а):
Речь идет о поиске (в идеале, с использованием wildcard, по первой колонке, которая для всех файлов однообразна) среди файлов на внешнем hdd средствами Linux без привязки к машине. Понятно, что оптимальным решением было бы NoSQL СУБД, но тут возникают ранее описанные проблемы + привязка к конкретной машине или конкретной СУБД. Elastic или mongo на VPS и заливка туда данных не рассматриваются. Что касается, Breach Compilation, то там не только однообразный формат и разделение данных черех двоеточие на мыло и пасс, но также и разделение данных по отдельным папкам и файлам в зависимости от первых букв строки, что позволяет ускорить поиск через специальный скрипт.
Не знаю в чем ваша проблема, если классические решения вас не устраивают. Вероятно в том, что вы ищите легких путей...
Лично мне, для своих целей хватает Кроноса, он мне удобен, я могу откуда угодно сколько угодно копий запустить. Поиск? Ну в зависимости от условий, 10 секунд, тысячи таблиц, выборка из миллиардов значений. Конечно, можно поработать и будет в разы меньше секунд, но я не настолько тороплюсь, что бы месяц возиться с данными выиграть прирост секунд запроса....
Не агитирую, но у меня свои обмены, партнеры. Именно в формате Кроноса получается что всё рационально. Если в веб транслировать задач не стоит (внутренние решения под это дело корявые), то вполне оптимально. Хотя, конечно, многие плюются, что Кронос дерьмо, хотя по факту они его попросту не умеют готовить ))
Каждому свое.
 
Xм, возможно, действительно, есть смысл Кронос попробовать. Правда, у меня система в английской локализации, поэтому Кронос отображается крякозябликами. Осталось понять, как решить эту проблему и как залить данные туда. Если заливка идет быстро, возможно, это будет более оптимально, нежели собирать свой индекс.
 
Igrmr сказал(а):
Hmm, maybe it really makes sense to try Kronos. True, my system is in English localization, so Kronos is displayed as mallards. It remains to figure out how to solve this problem and how to upload data there. If the fill is going fast, it may be more optimal than collecting your own index.
Did you read my answer?
 
Кронос не поддерживает экзотические языки, UTF-8 он поддерживает, но не всё. Ну и то, начиная с 7.0 он поддерживает. СУБД даже не планируется шапочно англофицировать, не то что там ее представлять.
Под свои цели. Что до того что заявляют что это дерьмо, то извините, как такие клиенты могут им пользоваться, а это ФСБ РФ, МВД РФ, Таможенный комитет РФ, Центральный Банк РФ, ФСИН РФ, Счётная Палата, Сбербанк России, РОСАТОМ и целый ряд правоохранительных систем бывшего СНГ...
Это ИСУБД, инструментальная СУБД ориентированная на легкость входа и администрирования. Там всё допиливается. Не хватает формул, есть скрипты и полная поддержка lua.
Тем кто говорит что это дерьмо, мне как-то попала рабочая база ФСКН до его расформирования, региональные базы велись в Кронос. И я очень удивился администратрированию этой базы в Кроносе. Невероятные вещи реализованы.
Проблема критиков Кроноса в том, что они ни разу, ничего не администрировали, все их познания заключаются в тыке каких-то баз. Они попросту не понимают возможностей и тем более преимуществ Кроноса перед другими СУБД, почему же это выбирают. Так что....
 
Igrmr сказал(а):
@ [USER = 207244] DonDu0 [/ USER], data is to be accessed locally from different machines, so probably in that case MongoDB is not a good solution.
It's Working Good the local network
Is there any problem with you ?!
if you search for alternative solution it will be difficult to import to customize

Good Luck
 
рекомендую manticoresearch / sphinxsearch (работаю больше с первым), данные хранит в сжатом виде - проверял + индексирует , по пожиранию памяти в разы, если не на порядке меньше Эластика,

еще интересным выглядит Clickhouse - говорят, по строкам очень быстро ищет, заточен под like %% выражение, но сам кликхаус, конечно, не для поиска
 
Sorry, english person.

Don't know exact end goal of what you want, but this was first thing that came to mind:
github.com

GitHub - rsyi/whale: 🐳 The stupidly simple CLI workspace for your data warehouse.

🐳 The stupidly simple CLI workspace for your data warehouse. - rsyi/whale
github.com github.com

Here are a couple other repos that may be useful:

github.com

GitHub - PyTables/PyTables: A Python package to manage extremely large amounts of data

A Python package to manage extremely large amounts of data - PyTables/PyTables
github.com github.com
github.com

GitHub - oxnr/awesome-bigdata: A curated list of awesome big data frameworks, ressources and other awesomeness.

A curated list of awesome big data frameworks, ressources and other awesomeness. - oxnr/awesome-bigdata
github.com github.com
 
admin


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх