DizZa: ох...
предположим, у Вас есть текстовый лог. к примеру, классика - дата-время-источник-сообщение. разделитель - табуляция. с первыми тремя полями все понятно, это отдельные сущьности, их надо затянуть в отдельные поля. сообщение - штука сложная. там может быть от надписи "ок" до первого тома "Война и мир" (утрирую конечно, но сообщение о ошибке java бывают большими. очень. и многстрочными).
так вот - задача логсташа такую запись (это может быть как 1, так и до-фига-строк) разбить на отдельные дату-время-источник-сообщение и отдать в эластик. Эластик ЭТО возьмет, и в зависимости от настроек как-то сохранит. вот поле "источник", к примеру, логичнее всего хранить как 1 слово, искать по первой букве этого слова вы будете маловероятно. А вот сообщене надо анализировать (считайте - построить индекс по этому полю). и в таком случае Вы потом сможете искать по любой части строки.
подводя итог. совет. Вы планируете ввязаться в непростое дело. у Эластика есть неприятная особенность - если в начале накосячить с индексом (мэппингом, анализаторами), потом исправляется это только переиндексацией. что хлопотно и затратно. Поищите кого-то, кто уже делал подобные вещи и наймите. собрать с вас ваши хотелки и грамотно запустить процесс - дело не самое сложное. сэкономите и время и нервы.
DizZa: вот что не расскажут - то не расскажу. Знаю, что анализаторов несколько (https://www.elastic.co/guide/en/elasticsearch/refe..., а вот использовал я только либо дефолтный, либо никакой. Логсташ тут не причем, он только данные парсит(бьет на поля, может установить тип, модифицировать данные и т.д.) и запихивает в эластик.
Что такое "FULL TEXT INDEX" в MySQL представляете себе? Вот анализатор - аналог.
lxfr: скрипт на баше будет замечательно делать все, что Вы хотите. Включая бэкап на S3, например. Но если Вы ищите готовый инструмент - стоит это указать в вопросе.
nezzard: попробуйте сделать systemctl stop firewalld. что-то мне подсказывает, что файрвол блокирует. Если да, оно - включайте обратно и добавляйте отдельное разрешающее правило.
DizZa: ок, с объемом хранения понятно. емкость дисков можете посчитать сами, для верности умножте на 2 =). и лучше SSD. Что до памяти и количества нод, то тут многое будет зависеть от того что и как будете искать. Если просто поиск "руками" по каким-то полям, без агрегаций/среднего/уникальности и поиска по всему объему разом - то больших проблем не вижу. По моим ощущениям все хорошо пока индекс влезает в HEAP_SIZE. Делайте отдельный индекс по дням, сделайте несколько нод.
что до "аналировать-не анализировать" - то все просто. Это как поиск по LIKE и по =. Если Вас устраивает поиск по "только точному соответствию" - не анализируйте (пример - тип события в логе). Если планируете искать по части строки - анализируйте. Анализаторов, к слову, несколько.
а обновления в таблице у Вас тоже будет порционно? Если нет ( к примеру обновилась только одна строка) - то что делать? ждать еще 999 или обновлять файлы сразу?
Максим Медведев: не понял замечания. сделайте LOAD DATA INFILE во временную таблицу, далее делайте с ней все, что хотите. Ваши несчастные 200К строк залетят в БД за секунды
qqignatqq:
Перейдите на страницу Structure соответствующей таблицы.
Кликните по Change в колонке Actions соответствующей колонке с date/datetime/timestamp.
Выберите Text/Plain: Dateformat из выпадающего меню Browser Transformation.
Вставьте 0,'%d.%b.%Y','local' опции трансформации (?).
Сохраните изменения и вернитесь обратно на страницу с браузером таблицы.
предположим, у Вас есть текстовый лог. к примеру, классика - дата-время-источник-сообщение. разделитель - табуляция. с первыми тремя полями все понятно, это отдельные сущьности, их надо затянуть в отдельные поля. сообщение - штука сложная. там может быть от надписи "ок" до первого тома "Война и мир" (утрирую конечно, но сообщение о ошибке java бывают большими. очень. и многстрочными).
так вот - задача логсташа такую запись (это может быть как 1, так и до-фига-строк) разбить на отдельные дату-время-источник-сообщение и отдать в эластик. Эластик ЭТО возьмет, и в зависимости от настроек как-то сохранит. вот поле "источник", к примеру, логичнее всего хранить как 1 слово, искать по первой букве этого слова вы будете маловероятно. А вот сообщене надо анализировать (считайте - построить индекс по этому полю). и в таком случае Вы потом сможете искать по любой части строки.
подводя итог. совет. Вы планируете ввязаться в непростое дело. у Эластика есть неприятная особенность - если в начале накосячить с индексом (мэппингом, анализаторами), потом исправляется это только переиндексацией. что хлопотно и затратно. Поищите кого-то, кто уже делал подобные вещи и наймите. собрать с вас ваши хотелки и грамотно запустить процесс - дело не самое сложное. сэкономите и время и нервы.