На AliExpress есть много вариантов по fanless PC (имхо, есть смысл брать i5 8 поколения), у самого дома работает уже 2 года (на i7 7500U), тянет на минимально/средних даже старые игры типа Skyrim. Если не ставить жесткий диск, абсолютно бесшумный.
Но ПК от китайцев — это лотерея, к этому надо быть готовым.
История 2016 года, сложно вспомнить, крутили отладку по ElasticSearch, думали, что проблема в нем или в том, как мы его используем. Решение вернуться на CMS было уже от «давайте еще идей», и то, что оно помогло, моментально перевело ситуацию к «работает — не трогай».
Было уже очень давно, сервера в изолированной зоне, даже вынести и проанализировать на внешнем сервисе было проблемой, тут уже просто поделился результатом почти месяца выяснения причин.
У нас, при высокой нагрузке по индексации, периодически одна из дата-нод получала очень высокую нагрузку и уходила в себя, остальной кластер простаивал и ждал пока она разгрузится. Грешили на железо, но проблема была плавающая (проблемная дата нода проявлялась случайно) и на низкой нагрузке не проявлялась. В итоге помог возврат с G1 на CMS. Если ничего не путаю, это был ES2.х и JavaSE 8u25.
Неочевидный лимит на число документов на шард (не более 2 147 483 647 документов) .
Странное поведение, когда несколько инстансов эластика на 1 сервере работают быстрее чем один (на тех же CPU и дисках, у нас магическая цифра 25 тыс документов в секунду на 1 датаноду).
Если по каким-то причинам маппинг на индекс не применился по темплейту и эластик его придумал сам (авто маппинг), самые необычные глюки при последующем поиске в данных между нормальными и «странными индексами». Хотя данные в _source выглядят идентично
Спасибо за утилиту, попробую! По плану запроса, в Oracle план реально выполняемого запроса и план через explain могли сильно разнится и вводить в заблуждение, тут и спасал sqlid с актуальным планом выполняемого запроса. В PG такие проблемы актуальны или он все же стабильней, плану через explain можно верить?
Авто-удаление исторических данных, скажем старше N дней (скажем 45 дней), как я понимаю в MergeTree данные партициируются за месяц и простого варианта нет? Или же создавать, таблицы одну на N дней и объединять их через MERGE и читать данные через неё, а если данные устарели удалять физические таблицы?
Как быть, если в результате нужны все столбцы (строки из исходного лога)? Заводить отдельную колонку и хранить в ней строку лога без обработки?
Спасибо за ответ, да, масштабно! Было бы интересно почитать про технические моменты такого решения, если сможете хотя бы частично приоткрыть детали? Вообще, поскольку это key-value, то решение наверняка очень низкоуровневое, вплоть до создания групп ключей под разные нужды, организация кластера и отказоустойчивость, отдельная проблема параллельные поиски и вставки (наверное для embed решения это тоже не очень тривиально)?
Еще вопрос, будете ли открывать какие-то сопутствующие технологии, появляющиеся при разработке кейса по почте (решения для кластера / полнотекстовый поиск / может быть сжатие)?
На прошлогоднем highload++ говорили, что Sophia подходит под логи, но не применима под реально долгое хранение большого объема (сотни терабайт). На какой максимальный объем данных её стоит её рассматривать, относительно кейса с логами?
Если правильно понимаю, при большом объеме вариант или гибридный (память+диск) либо только хранение на диске.
Стоит ли её вообще рассматривать в таком кейсе: постоянное добавление данных, но при этом достаточно ресурсоемкие выборки большого количества (2-5+ млн.) объектов.
Вообще-то Sublime Text платный, бесплатна только его пробная версия (пруф).
Самый большой минус — отсутствие встроенного отладчика процедур/функций, еще, видимо, нужна ручная работа при добавлении новых объектов в БД? Придется дергать скрипт выгрузки списка для подсветки каждый раз при добавлении чего-то нового. В целом же подход довольно интересен, спасибо.
Сбор информации с нескольких БС осуществляется за счёт LMU и SMLC модулей в составе LBS (LCS) системы оператора. Модули LBS интегрируются в сеть и работают по той же SS7. В тоже время платформа точного определения местоположения, с которой работают абоненты, общается по MAP с MSC и HLR. Можно ли стандартными MAP запросами получить уточнённое местоположение, если у оператора установлен LBS? Делается ли это через тот же MAP Provide Subscriber Location?
А как у этих светодиодных ламп с мерцанием? Брал под цоколь GU5.3 диодные на 5W 3000K, по сравнению с галогенными (35W) ярче, но ощутимо «холодней». Что не понравилось, если сделать простой тест: оставить включенными только диодные лампы и перед лицом на вытянутой руке быстро поводить ладонью, видны промежуточные положения, у галогенных движение плавное.
Чем удобней секционирование в Oracle:
1.1. Меньшее количество операций для создания, настройки и переделок. Больше вариантов секционирования (линк1, link2). Тут и способы как разбить таблицу и вложенные секции и еще много чего. В 11g сделали автоматическое создание новых секций.
1.2. Для ПО — это одна таблица, всю внутреннюю кухню БД ведет сама (посмотреть что внутри можно через системные словари и вьюшки).
По скорости:
2.1. Для вставки не нужен «for each row» триггер, вы вставляете данные, а БД сама понимает куда их надо заносить. Тут можно выкрутится через RULE, но согласитесь «удобство» работы страдает.
2.2. Oracle нормально и без заметных просадок работает тысячами партиций, в доке по Postgres (есть интересная фраза «Partitioning using these techniques will work well with up to perhaps a hundred partitions; don't try to use many thousands of partitions.»)
2.3. Спорный момент, но в Oracle можно сделать глобальный индекс по всем секциям, что в некоторых случаях может дать прибавку по скорости.
А кто-нибудь работал с коммерческим Postgres (ака EnterpriseDB Advanced Server )? Судя по рекламе там очень много вкусностей именно для переходящих с Oracle (планировщик задач в БД, нормальное секционирование таблиц, пакеты для процедур и т.д.), насколько не врет реклама?
Вы хорошее дело делаете, интерфейс сбера реально ужасен, убеждаюсь в этом каждый месяц. Буду следить за продолжением статьи!
Я про то, что, возможно, для технически подкованных пользователей стоит заложить некую «фишку»: аналог «избранное»/«любимые получатели»/«быстрый платеж» или как-то так. Для продвинутых будет понятно и просто, для тех кто не разбирается — боюсь без помощи и не разберутся, но ориентироваться только на них было бы как-то однобоко (особенно в свете того что я писал про регионы, тут пользуются все — альтернатив почти нет).
>>Другими словами аудиторию киосков можно описать так: люди, которые не достаточно разбираются в современных технологиях, чтобы пользоваться интернет-банкингом.
Немного неверное допущение, у меня банально нет в Сбербанк-Онлайн тех коммунальных платежей которые есть в их терминалах оплаты: «это же регионы, детка»!
Но ПК от китайцев — это лотерея, к этому надо быть готовым.
discuss.elastic.co/t/indexing-performance-degrading-over-time/40229
Еще вопрос, будете ли открывать какие-то сопутствующие технологии, появляющиеся при разработке кейса по почте (решения для кластера / полнотекстовый поиск / может быть сжатие)?
Если правильно понимаю, при большом объеме вариант или гибридный (память+диск) либо только хранение на диске.
Стоит ли её вообще рассматривать в таком кейсе: постоянное добавление данных, но при этом достаточно ресурсоемкие выборки большого количества (2-5+ млн.) объектов.
Самый большой минус — отсутствие встроенного отладчика процедур/функций, еще, видимо, нужна ручная работа при добавлении новых объектов в БД? Придется дергать скрипт выгрузки списка для подсветки каждый раз при добавлении чего-то нового. В целом же подход довольно интересен, спасибо.
1.1. Меньшее количество операций для создания, настройки и переделок. Больше вариантов секционирования (линк1, link2). Тут и способы как разбить таблицу и вложенные секции и еще много чего. В 11g сделали автоматическое создание новых секций.
1.2. Для ПО — это одна таблица, всю внутреннюю кухню БД ведет сама (посмотреть что внутри можно через системные словари и вьюшки).
По скорости:
2.1. Для вставки не нужен «for each row» триггер, вы вставляете данные, а БД сама понимает куда их надо заносить. Тут можно выкрутится через RULE, но согласитесь «удобство» работы страдает.
2.2. Oracle нормально и без заметных просадок работает тысячами партиций, в доке по Postgres (есть интересная фраза «Partitioning using these techniques will work well with up to perhaps a hundred partitions; don't try to use many thousands of partitions.»)
2.3. Спорный момент, но в Oracle можно сделать глобальный индекс по всем секциям, что в некоторых случаях может дать прибавку по скорости.
Я про то, что, возможно, для технически подкованных пользователей стоит заложить некую «фишку»: аналог «избранное»/«любимые получатели»/«быстрый платеж» или как-то так. Для продвинутых будет понятно и просто, для тех кто не разбирается — боюсь без помощи и не разберутся, но ориентироваться только на них было бы как-то однобоко (особенно в свете того что я писал про регионы, тут пользуются все — альтернатив почти нет).
Немного неверное допущение, у меня банально нет в Сбербанк-Онлайн тех коммунальных платежей которые есть в их терминалах оплаты: «это же регионы, детка»!