Юрий Соколов funny_falcon

Поддержу: OCC (optimistic concurrency control) может реализовываться и поверх «одноверсионных» стораджей. А блокировки приходится делать и с MVCC, и с OCC во всех проявлениях, и вопрос только в гранулярность и времени жизни блокировки.

С переплатой. А в остальном справедливо.

Так а кто станет контрибьютить в хрень, которая не работает без бэкенда, на реализацию которого нужно убить полгода?

Не помню, чтобы Ruby менялся под RoR.
А вне Web (кроме RoR используют еще Sinatra и еще несколько других) он слабо используется потому, что просто качественных либ/фреймворков для остального так и не смогли написать:

• не глючных Gui нет, емнип
• альтернативу NumPy начали писать, но догнать не могут (не глворя уже об Apache Arrow).

Как мне кажется, есть две причины:

• В руби всем нравится гибкость в написании DSL. А в областях, где исторически менее принято использовать DSL, гибкость руби становится не очень нужной.
• это глубоко имхо, но рубишный GC вставлял палки в колёса. Для GUI люди ошибались с привязкой рубишных объектов с элеметами ui, в результате получали трудновоспроизводимые баги. А для вычислений, отложенное освобождение не позволяет хорошо следить за потреблением памяти (хотя Julia как-то с этим справляется).

В обоих случаях питоновский RC оказался более удобным: менее error prone в GUI и более предсказуемым в числодробилках.

А почему да? Что они выиграют от того, что приложение, заточенное на их бэкенд, станет opensource?

Я ж откуда знаю. Где-то ж Владислав находит "мидлов за 30", готовых работать "за опыт".

Мидлов за 30? Вы с джуниорами не путаете? Да и то, это джуниоры с окраин какие-то.
Или вы про индусских мидлов?
Или я отстал от жизни, и мидл — это новичек, а джуниор — это человек, впервые коснувшийся пальцем клавиатуры не сидя на коленках отца?

Я, конечно, сейчас поведу себя как тролль… но раззорившаяся компания как пример для подражания…
В любом случае, спасибо за ответ. Удачи вам во всем.

И, если не трудно, расскажите, почему Riak:
из каких альтернатив выбирали? почему выбрали? какие впечатления в процессе эксплуатации сформировались?

Bashoo уже не существует, емнип. Я думал, Riak умер. Его кто-то еще поддерживает?

А что писать про язык, который просто работает?
Да, он не самый удобный для всего на свете, не самый быстрый на свете, не самый элегантный.
Но он позволяет "get the job done", при этом без больших временных затрат на первом этапе, и помогая удобными профилировщиками на этапе оптимизации. При необходимость использовать другой язык для оптимизации (asm, C, C++) возникает намного реже, чем в других прикладных рантаймах.

А вообще, я до сих пор думаю, что, если бы JVM не выпилила в свое время свои зелёные потоки (или вовремя бы вернула), то Go бы не взлетел.

Для систем с ограниченными ресурсами похоже что Go действительно не очень хорошо вписывается.

Странно, правда, что Dart при этот в рекомендуемых оставили. Видимо решили хотя бы один прикладной язык оставить.

Только А1 и медленнее раза в три. Так что, брать их можно только для тренировок.
А вот M6g нужно пробовать. Возможно они и правда хороши.

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

Тогда от PostgreSQL вы вообще бежите как черт от ладана?

вынуждена сразу писать в датафайлы, тогда как все конкуренты могут считать транзакцию подтвержденной после записи дельты в лог транзакций.

1) это не значит, что другие базы сразу в датафайлы не пишут. Пишут. Может не прям сразу, но пишут. Просто fsync делают только на log.
2) зато файербёрду не нужно прокручивать лог на старте в случае чего, не нужно иметь две сущности (датафайлы и лог). Если они смогли сделать так, что rps не сильно страдает, то чем же это плохо?
Конечно rps будет страдать. Но:
a) во многих охвученных применениях база локальна небольшому числу пользователей, а значит rps заведомо небольшой
б) некоторые озвученные применения подразумевают немаленький rps, а огнептах при этом справляется. Странно да?
Лог транзакций не является ценностью сам по себе. Это всего лишь инструмент решения задач. Если ОгнеПтах нашел другой инструмент, то что в этом плохого?

SQLite3 очень шустро импортирует csv файл в пустую базу (в классическом режиме. С WAL тормозит). Тем более, если посортировать предварительно.

SQLite3
Сортированный файл, обьявленный как csv через встроенный импорт csv влетит пулей.

Автор как будто вышел из комы: водители всегда ставили нам оценки. Я несколько раз мешкался выбираясь из такси и видел, как его ставили. И год назад, и два.
Рейтинг у пассажира был всегда, просто теперь пассажир его видит.

Постгресс на двух сокетах ведет себя худе, чем нА одном. Т.е. можно тренироваться писать NUMA aware приложения

Проблема не в том, что копировали. А в том, что задвигали тех, кто мог сам делать.

У нас были и ученые, способные делать отечественные компьютеры и развивать отрасль. И разработки были свои.

Но советское руководство послало их на три буквы, и заставляло копировать.

Как я использую телефон, вряд ли я чаще 30 раз в день его раскладывал. Т.е. мне на три года бы хватило.
Но 100к у самсунга впечатляют больше.

Интересно, почему они не стали хранить метаданные в одном ключе, сериализовав их в msgpack или protobuf? Запросы по метаданным все равно не будут сейчас быстрее работать, т.к. значения не в ключе. А места получается в несколько раз больше занимает, и локальность страдает. Кмк, в текущей схеме минусов больше, чем плюсов.

Ой да ладно. Проблемы с транзакциями существуют когда в одной транзакции трогается несколько ключей. Если же каждый раз щупается один ключ, то ни тебе дедлоков, ни тебе отката трагзакций. Все очень даже неплохо масштабируется, если правильно готовит.

Да, в редисе есть возможность использовать и что-то, что они называют транзакциями, и Lua процедуры. Но на практике этим пользуются невероятно редко.

Кстати, в KeyDB весь выигрыш только из распараллеливания сетевого взаимодействия. Вся работа с данными идет под глобальным локом.
Т.е.:
а) сетевое взаимодействие настолько накладно, что есть выигрыш от мношопоточности
б) типичная работа с данными настолько быстрая (в redis/keydb), что делать ее под глобальным локом не больно. А значит нет дедлоков и откатов транзакций.
в) конечно, если поставить keydb на 32 ядерную машину, проблемы от глобального лока начнутся. Так что им есть куда расти.

Вот я сейчас использую redis-cluster. 16 физических шардов по три процесса на сервер по две реплики. Т.е. 32 сервера, 48 редисных шардов, 96 редисных процессов. И я в серьез подумываю про KeyDB, т.к. это позволит мне сэкономить гору процессорного времени. Почему? Да потому что на 48 шардов очень плохо работает пайплайнинг запросов. А он экономит цпу как на клиенте, так и в самом редисе. А с keydb у меня будет всего 16 шардов.

Останавливает меня только репликация: сейчас каждый редисный шард по 6GB, и мне приходится применять не тривиальную конфигурацию, чтобы редис физически был способен отреплицировать после рестарта реплики без отвала по достижению своих внутренних лимитов. Я сильно сомневаюсь, что KeyDB сможет отреплицировать 18GB.

Думаю, либо ваш коннектор не умеет сам redis-sentinel, либо вы не догадались его приготовить.

Если коннектор умеет redis-sentinel, он будет ходить напрямую, без proxy.

Вот не понятно, чем XFS, или любая другая posix совместимая файловая система спасла бы от незакрытых файловых дескрипторов на 20ГБ логов.

Вы просто хотели поделиться своей болью от EXT4? Так напишите пост, вместо того, чтобы комментарии не по теме оставлять.

Чтение, по идее, тоже лучше параллельными/асинхронными запросами вместо IN, когда много партиций задействовано.

Товарищ подсказывает по Кассандре:

• не используйте батчи для записи во многие партиции. (Об этом даже DataStax пишет)
• используйте параметризованные запросы вместо склейки строк. Тогда и коннектору и кассандре будет проще разбирать запрос, чтобы понять в какой сервер его посылать.
• в коннекторе необходимо указать TokenAwarePolicy (хотя, вроде DataStax коннектор ставит ее по умолчанию)

Я не сварщик, но HBase все-таки не такой уж и тупой.

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

Мастер кластера отвечает за изменение метаданных. За хранение отвечает Сторож Зоопарка. Соответственно, если упал мастер кластера, то не получится поменять состав кластера или схему данных. Однако читать и писать данные вы сможете.

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

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

умрет с out of memory запросто как любая другая база, которая умеет сложные агрегации делать.

Ну зачем же так обобщать? PostgreSQL довольно сложно уронить по OoM. По крайней мере, одним запросом. Т.к он может сбрасывать промежуточные данные на диск. Конечно, и у него бывают промашки, но вроде бы редко.

Вот такой serial точно дырки будет иметь т.к. он не before commit.

Нет, не решил:

• after insert — это не тоже самое, что before commit. Между after insert и commit есть промежуток времени, в который может прилететь rollback.
• если используете честный before commit, то не можете в одной транзакции вставить связанные документы. Не знаю, правда, нужно ли это в контексте 1С и подобных систем.