• MVCC как один из способов обеспечения изоляции транзакций
    +2

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

  • Minitel: французский кузен интернета
    +1

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

  • Новое приложение «Медузы». Почему Flutter?
    0

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

  • Новое приложение «Медузы». Почему Flutter?
    0

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


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

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


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

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

  • Новое приложение «Медузы». Почему Flutter?
    0

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

  • Создание псевдотрёхмерной гоночной игры
    +1
    Спасибо за самые классные пять минут за последние несколько недель!!!
    Такие ностальгическая волна по детству…
  • Сколько я просадил на создании мобильного приложения, и как его возродил коронавирус
    0

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

  • Сколько я просадил на создании мобильного приложения, и как его возродил коронавирус
    +3

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

  • Антигравитация это не то что вы думали
    0
    Я даже перепроверил дату, думал, что 1 апреля опубликовано.
    Пойдите на физ-мат вольным слушателем. За 5 лет вам всё объяснят. Сами потом расчитаете, что к чему.
    А может даже на Coursera есть курсы. Скорее всего есть. Пройдите.
  • RBK.money выпустила первый в мире open-source платежный процессинг — творим будущее вместе
    0

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

  • RBK.money выпустила первый в мире open-source платежный процессинг — творим будущее вместе
    0

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

  • RBK.money выпустила первый в мире open-source платежный процессинг — творим будущее вместе
    0

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

  • Алексей Найдёнов. ITooLabs. Кейс разработки на Go (Golang) телефонной платформы. Часть 1
    +1

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


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

  • Алексей Найдёнов. ITooLabs. Кейс разработки на Go (Golang) телефонной платформы. Часть 1
    0

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


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

  • Ampere Altra — первый в мире 80-ядерный ARM-процессор
    0

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

  • Тюнинг Firebird и Linux для БД размером 691 Гб с 1000+ пользователей
    0
    у фб мусор в датафайла, файлы распухают, все вокруг вынуждены делать много больше чтений, чем необходимо. требуется сборка мусора, что влечет тормоза и совершенно лишние приключения.

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


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

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

  • Ускорение поиска в Have I Been Pwned до 49 микросекунд (С++)
    0

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

  • Ускорение поиска в Have I Been Pwned до 49 микросекунд (С++)
    +1

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

  • Рейтинг в Яндекс.Такси: короткий пост на серьёзную тему
    +1

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

  • Китайская Zhaoxin выпустила 8-ядерные процессоры «для DIY-энтузиастов»
    0

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

  • Николай Прохоров: «Американские гиганты за счет массовости подавили все новое»
    0

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


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


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

  • Тест Motorola Razr показал, что смартфон перестает нормально складываться через 27 000 циклов
    0

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

  • KeyDB как [потенциальная] замена Redis
    0
    > Т.е. 8 клиентов на 8 редис процессов могли бы идти по 8 сокетам. Все на разных ядрах.
    А у вас 8 клиентов идут на 8 редис тредов через 1 сокет все в перемешку.

    «Клиентов» в одном процессе — десятки. Редисов всего 96. Если по вашей логике, то это 1000 сокетов с одного только процесса клиента. А тачек клиентов у нас тоже не один десяток.
  • KeyDB как [потенциальная] замена Redis
    0
    > А могло бы всё идти по разным сокетам и без конкурентности… В чём профит, непонятно. Разве что какие-то внутренние проблемы редиса с большим кол-вом сокетов.

    Когда начнёте профилировать, поймёте: экономия цпу от 10% до 40%. Когда это экономится на клиенте, это не так может заметно. А вот когда в редисе, то очень чувствительно!
  • KeyDB как [потенциальная] замена Redis
    +2
    Учитывая, что это php, и вряд ли они делали руками пайплаининг, редис упирался в sys cpu: чтение/запись в сеть.

    С хорошим pipelining редис может миллион rps на половинке ядра выдать.
  • KeyDB как [потенциальная] замена Redis
    0
    > сессии юзеров, фоновые задачи, csrf токены, межсервисные локи, различные другие токены, коды подтвеждений sms — всё отлично там хранится.

    Т.е. любые данные, которые вроде и не хотелось бы потерять, но если потеряются, то и хрен с ними. Да, такое можно.

    > у редиса два механизма записи на диск — снапшоты и AOF. не вижу повода не хранить там даже важные данные.

    А я не вижу повода хранить:
    — AOF и snapshot к сожалению друг о друге не знают.
    — snapshot делается редко. Его рассматривать вообще нет смысла.
    — запись в AOF идёт в том же треде. Если диск притормаживается (реплика подключилась), то всё встаёт колом. И ЧТЕНИЕ ТОЖЕ!
    — а диск в том числе подтормаживает, когда AOF файл захотел сделать себе rewrite. Ну или если реплика приконнектилась.
    — AOF не содержит номера команд. Потому Redis не может его использовать для наливки слейва. И слейв не может его использовать, если вдруг рестартанулся. Единственный выход у Редиса — откладывать новый снапшот (здравствуйте тормоза диска) и копить изменения в памяти. Чтобы отреплицировать 6ГБ инстанс мне приходится в настройках держать `client-output-buffer-limit replica 0 0 0` и `repl-backlog-size 200mb`.

    Для сравнения, Tarantool:
    — снапшоты и xlog файлы образуют единый механизм,
    — xlog файлы содержат номер каждой операции
    — реплика читает свой снапшот, проигрывает свои xlog и только после этого коннектится к мастеру и читает с последней операции
    — мастер сперва шлёт данные с xlog файлов с нужного места (переслав перед этим уже готовый снапшота, если реплика новая или слишком отстала), и только когда реплика догоняет, переключается на inmemory посылку (емнип).
    — данные в xlog пишутся в соседнем треде. Основной тред продолжает работу и спокойно обслуживает read запросы (и готовит к записи новые write запросы) даже если диск подтупил слегка.
  • KeyDB как [потенциальная] замена Redis
    0
    Допустим, у нас Lua процедуры интенсивно используются в Redis. Но работают в основном с одним ключом (с одним Hash). В redis-cluster вообще сильно не попользуешься «разными ключами». Можно, конечно, если использовать фигурные скобки а-ля `namespace:{my-shard-key}-subkey`, но напряжно.

    А что я должен был понять?
  • KeyDB как [потенциальная] замена Redis
    –3
    > Если хранение данных, то нужны «часто».

    Храните данные в Redis?… у вас стальные яйца, я вам скажу. Зная, как работает Redis, я бы не стал в нём ни чего хранить.

    Если вам нужно inMemory, посмотрите хотя бы в сторону Tarantool. Он намного надёжнее в плане сохранности. А так же гибче. И вряд ли медленнее.
  • KeyDB как [потенциальная] замена Redis
    0
    > KeyDB с оверхедом от многопоточности будет быстрее чем редис с оверхедом от отсутствия пайплайнинга. Или будет?

    Будет. Оверхед от многопоточности в KeyDB — это взять мьютекс перед походом в хэш-мап, и отпустить после.

    > И что за кейс где нужен пайплайнинг — это же не кэширование?

    Как это «не кэширование»? У нас весь бэкенд шлёт до 2М запросов в секунду в редис именно за кешем. «не кэш» использования редиса у нас очень мало.

    Просто наш коннектор умеет делать «прозрачный пайплайнинг», когда запросы из параллельных горутин в один сокет пишутся.
  • zetcd от CoreOS: Заменяя ZooKeeper на… хранилище etcd
    0

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

  • KeyDB как [потенциальная] замена Redis
    0

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


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


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

  • KeyDB как [потенциальная] замена Redis
    +2

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


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

  • KeyDB как [потенциальная] замена Redis
    +1

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


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

  • Внезапно, одной лишь системы сборки мусора недостаточно
    +1

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


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

  • Битва двух якодзун, или Cassandra vs HBase. Опыт команды Сбербанка
    0

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

  • Битва двух якодзун, или Cassandra vs HBase. Опыт команды Сбербанка
    +1

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


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

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


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


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


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


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

  • Битва двух якодзун, или Cassandra vs HBase. Опыт команды Сбербанка
    0
    умрет с out of memory запросто как любая другая база, которая умеет сложные агрегации делать.

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

  • 1С — Добро и зло. Расстановка точек в холиварах вокруг 1С
    0

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

  • 1С — Добро и зло. Расстановка точек в холиварах вокруг 1С
    0

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


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