Теперь можно будет переписать человека… и внести ещё багов. А также бекдоров, вирусов нового типа…

Конечно, если программа такая забагованная, то сколько труда стоило им сделать ленту нормально.
Здесь, наверно, должна быть картинка с вылетающим из окна монитором :D

>Плохой код
В Футураме это было не заметно:)

Радио Рекорда больше нет говорят, теперь с 1апреля будет RaveFM. Ага, так и поверил!

На днях только закончили страдать с этой проблемой, а так да, надо бы. Вот только джава оракловая, как того рекомендует Elasticsearch.

Восьмая, конкретно 1.8.0_72

промахнулся

У нас тут своя, нехорошая история с GC.
Поставили как-то кластер Elasticsearch на десяток машин, при этом решили посмотреть, как будет вести себя G1. Кластер работал… пару дней, дальше перезапуск, из-за появлявшейся тормозящей кластер ноды по каким-то до сих пор невыясненным причинам.
Симптом: все потоки для балков прожигали время в таблице TheadLocal.ThreadLocalMap.table. Судя по дампам, таблица разрасталась и имела большой диапазон идущих подряд Entry, на которых как раз спотыкается цикл в методе ThreadLocalMap.expungeStaleEntry() (видимо тот самый цикл, что unlike Knuth). Вычеркнуть пытался ReentrantReadWriteLock всего лишь свой readHolds. Ну и вообще, в хот-тредах эластика часто появлялись методы ThreadLocalMap, вроде getEntryAfterMiss(), долго работающие с этой разросшейся таблицей.
На GC не думали, конечно, искали баги в коде… пока не сменили сначала на дефолтовый, потом на CMS. В обоих случаях проблем не было, только при G1 проявлялась такая проблема. Гадай теперь, что виновато: алгоритмы, тюнинг или железо.

Кстати, это на десктопе нет, а как же J2ME (земля пухом) и андроид? Не знаю как на андроиде, там всё-таки можно взять C/C++, но J2ME? А как же Opera Mini? Там было даже немного яваскрипта :D
Да ей наверно до сих пор пользуются. И это на кирпичиках с около 2мб хипа. Как раз "более-менее вменяемый браузер" на java :)

Тестировали даже не на той версии, что сейчас используем, но всё же тогда надо было решить "брать или не брать". На тестовой машине с ES 2.0 doc_values просадил скорость индексации где-то на 15%, решили тогда отказаться. Сейчас наверно лучше, не знаю.
Кластер большой, к тому же по паре инстансов для обхода "ограничения" размера хипа в 32гб. Скорость 20-25к/с в среднем. Так что суммарно я думаю могло (может и сейчас) сильно просадить индексацию. А ещё сжатие включили, что сейчас оказалось пустой тратой, как мне кажется…
Сейчас уже подумываем взять обратно doc_values, на другом кластере для меньшего объёма данных.

Хотел сказать "переписать его на ваш любимы язык"

Зато на java написан Elasticsearch, который мы сейчас используем на большом кластере. Ничего, работает, я бы сказал отлично :) Можете сказать, что если переписать его на, то мы сэкономили бы парочку серверов. Но нет, он есть только на джаве.

Про doc_values могу сказать, что на hdd сильно просаживает индексацию, но память таки да, экономит. На ssd не использовали, но вроде не должно быть такого.

Это всё понятно, что оно может так случиться. У нас такого ешё не наблюдал, поэтому не знаю. Но я думаю лучше было бы действительно остановить запись (и тогда сработают всякие сигнализации) и не терять данные, тогда это не будет проблемой. Техническую проблему можно устранить и продолжить запись, а потерянные данные не вернёшь.

А как насчёт 2.х? Мы используем 2.1, а последняя сейчас вообще 2.3.
По поводу sql, то мы используем ES по назначению — поиск документов, поэтому нет потребности в каких-то сложных выборках или джойнах.

промахнулся

У нас ES используется как полноценная БД из-за мастабируемости и распределённого поиска, плюс к этому, за счёт кластера достигается высокая пропускная способность, а также лёгкость добавления ноды. Вроде бы PostgreSQL кластер тоже умеет, но не знаю как у него с вышеперечисленным, не говоря уже про MySQL. Но в ES нет такого мощного SQL, какой он есть в РБД. Так что каждому своё.
Конечно используем РБД, но скорее для вставки из ES для других приложений, которые используют их для своей работы.

Нам, к примеру, потребовалось в Elasticsearch посмотреть сколько места будут занимать данные и как будут выполняться запросы. Конечно, реальных данных нам никто не даст, NDA, всё такое. Первый велосипед был быстро набросан в скрипте на php, примерно генерируя то, что нам нужно. После уже обнаружили esBench, который собирает инфу на реальных данных, а потом мы можем по готовым шаблонам залить данные и сделать оценку. Но какой-то он заброшенный… У php ещё есть шанс :) можно будет посмотреть предложенные в этой статье инструменты.

Я вот что не пойму: это всё такая же группа галактик, которая движется к одной точке, но при этом Вселенная дальше продолжает расширяться и охлаждаться, или вся Вселенная движется к этой точке (Великому аттрактору)?