Импортозамещение

Ну!

Столько всего накидали - попробовать бы все )

ребят, а что в итоге сейчас модно использовать для максимально простого партиционирования?

Я бы брал rethinkdb, только там недавно был диссонанс среди разработчиков - то ли энтерпрайз за ним развалился, то ли опенсос сообщество взбесилось. Есть Elasticsearch, но читал что у него плохие результаты тестов jepsen, и не рекомендуется хранить в нем данные без бэкинг бд с лучшей гарантией консистенси. Автошардинг из коробки есть например у CockroachDB и Riak

https://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

вам партицирование или с данными работать?

мог просто ссылку кинуть :}

какой-то безумный вопрос

кто рекомендует эластик - вы серьезно предлагает поисковый движок?

мог просто ссылку кинуть :}

Мало ли, мож там за рекламу банят :)

Я бы брал rethinkdb, только там недавно был диссонанс среди разработчиков - то ли энтерпрайз за ним развалился, то ли опенсос сообщество взбесилось. Есть Elasticsearch, но читал что у него плохие результаты тестов jepsen, и не рекомендуется хранить в нем данные без бэкинг бд с лучшей гарантией консистенси. Автошардинг из коробки есть например у CockroachDB и Riak

там шардирование только на уровне таблицы, есть таблица, у таблицы есть мастер. таблица на два терабайта? все равно ее будет обрабатывать одна машиина

рефинк же умер, чо вы про него вспомнили

там шардирование только на уровне таблицы, есть таблица, у таблицы есть мастер. таблица на два терабайта? все равно ее будет обрабатывать одна машиина

ох

а кто-нибудь в курсе, на чем Algolia работает?

очень на эластик по апишке похоже, но в любом случае они там внутри допиливали

про rethink отчасти наврал, кажется, нужно пару минут

там шардирование только на уровне таблицы, есть таблица, у таблицы есть мастер. таблица на два терабайта? все равно ее будет обрабатывать одна машиина

Ну нет, один индекс может из N шардов состоять

очень на эластик по апишке похоже, но в любом случае они там внутри допиливали

да там наверное все in-memory. очень удобный сервис, особенно списки синонимов, но очень бьет по цене нужда в слейвах для сортировки/ранжирования по другим параметрам

Ну нет, один индекс может из N шардов состоять

Это я про ES

Не некоторых кейсах эластик сливает постгресу

я про rethink, но там тоже шарды, хотя я уверен, что на той неделе читал именно то, что написал. у эластик все в порядке.

о господи

я не знаю каким капсом надо написать, что эластик не имеет отношения к базам данных

Некоторые считают что относицо

но как он может проиграть, если у него и поиск, и kv доступ возведены в абсолют - не знаю

я не знаю каким капсом надо написать, что эластик не имеет отношения к базам данных

Почему?

потому что это поисковый движок

И что?

Яж говорил :)

Дефайн база данных

Нет

не эластик

Ок

Некоторые эластик юзают как бд

некоторые редис юзают, как бд

и файлы, как бд

И это мягко скажем прикольно наблюдать

некотоырм стоит подтянуть профессиональные навки

Зачем ? Нода монга и эластик спасут мир :)

Лол

Так чем эластик не бд?

хз короче, откуда я про rethink выятнул, disregard that

ты можешь назвать базой данных то, что не хранит данные?

Народ, с 9.5 до 9.6 мигрировать только через дамп\restore?

госпади, а я всего лишь хотел узнать какой плагин для нормального партиционирования сейчас стабильный для пг есть :)

ты можешь назвать базой данных то, что не хранит данные?

Нет, не могу.

но видимо нужно быть более конкретным

да норм база, только не очень данные надежно хранит https://aphyr.com/posts/323-jepsen-elasticsearch-1-5-0

Дяди шутят

Нет, не могу.

https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html чтд

Так чем эластик не бд?

вот краткое пояснение, там ссылка на тесты aphyrа: http://igor.kupczynski.info/2014/06/26/elastic-cap.html

Availability Reads and writes succeed on all nodes;

госпади, а я всего лишь хотел узнать какой плагин для нормального партиционирования сейчас стабильный для пг есть :)

пользуясь случаем прорекламирую pg_pathman : ) https://github.com/postgrespro/pg_pathman

for fuck's sake

пользуясь случаем прорекламирую pg_pathman : ) https://github.com/postgrespro/pg_pathman

насколько можно доверить важные данные? бекапы конечно есть, но не хотелось бы встрять

https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html чтд

Это ты к чему? Хочешь сказать в эластике нельзя хранить данные?

он не обязательно их хранит

Не обязательно да

Но тем не менее

Не хранит но база :)

тем не менее ты хочешь просто заездить меня до того состояния, в котором я соглашусь. мы поняли.

Это ты к чему? Хочешь сказать в эластике нельзя хранить данные?

Я бы не стал. У меня эластик несколько раз терял данные при обычном рестарте сервиса.

Не хранит но база :)

Не всегда хранит. Может хранить только индексы

ERROR: S client not available

нормально в нем хранятся данные

только это должны быть данные которые не страшно потерять )

и есть откуда восстановить если что

только это должны быть данные которые не страшно потерять )

+

Lol

У меня только индексы в эластике.

что не так-то? в идеале у тебя вообще должен быть воркер, который ходит по всей базе и перезасовывает ее в эластик

насколько можно доверить важные данные? бекапы конечно есть, но не хотелось бы встрять

работает стабильно на большинстве кейсов. Но нужно, конечно, погонять сначала на конкретно вашей тестовой базе

Lol

^

что не так-то? в идеале у тебя вообще должен быть воркер, который ходит по всей базе и перезасовывает ее в эластик

Так и есть.

я Алексу

Есть кейсы где он медленней на том самом перезвсовывании и скорости доступа к данным

Это вопрос того как работать с данными

чивось

Я с телефона не хочу расписывать кейс

Но встречал такое

@etkee какие-то пионерские тезисы. Эластик не база.. как должно быть в идеале ) мы оба понимаем, что есть варианты когда можно держать в эластике данные

да в файлах храните, чего там

В файлах тоже храним )

Можно хоть в мемкешке

Хоть в файлах

Вопрос сферы и скорости доступа к данным

извините, что я опять с rethink, но вот > All reads and writes to any key in a given shard always get routed to its respective primary про два терабайта был неправ, они поделятся на шарды внутри таблицы.

Господа, помогите, я уже не знаю что можно сделать. Бессилие от незнания устройства постгрес усугубляется тем, что "attempted to delete invisible tuple" даже не гуглится. Точнее гуглится, но намеков на решение не нахожу. Мне нужно просто сдампить те записи которые читаются, начать делать бекапы, и забыть этот кошмар. Я могу написать код, чтоб подергать данные rangeами, но в таблицах нет серийного pkey, по которому я мог бы планировать выборку. История вкратце: повисло ядро из-за corrupted md0. Я пересобрал md2 на котором были данные, fsck показал чистую ФС, скопировал pgdata на внешний диск, переустановил ОС и постгрес, но pg_backup отваливается на первой corrupted записи. Включил вот это: zero_damaged_pages = on ignore_system_indexes = on enable_indexscan = off enable_bitmapscan = off enable_indexonlyscan = off ...но оно не помогает от ошибок timestamp out of range, которые не получается DELETE из-за этой ошибки "attempted to delete invisible tuple". Попытка select * from tablename; заканчивается крашем процесса postgresql с Segmentation fault на ф-и heap_deform_tuple.

Такое чувство, что во время краша postgres не дописал или не закоммитил какие-то трансакции, и от них не может избавиться новый сервер.

а нельзя сделать просто order by и просто селектами бежать по записям "сверху вниз" по одной? Это займет гору времени, но код предельно примитивен

а нельзя сделать просто order by и просто селектами бежать по записям "сверху вниз" по одной? Это займет гору времени, но код предельно примитивен

Хмм, я как-то и не подумал, попробую как крайний вариант наверное. Может есть опенсорц скрипты для этого?

не знаю, я бы просто руками написал. С точки зрения кода это должно быть предельно примитивное творчество - селект по 1 записи, сохранение в csv. структуру придется выкачивать отдельно

А зачем в csv? Нельзя разве параллельно БД с такой же структурой развернуть и сразу туда сливать инфу?

Нужно же в конце концов рабочую базу иметь

С минимальной потерей инфы