clayrat
→ rtsome
19.06.2012 18:35
смотри, какой я тебе джоб оффер нашел: http://intercrossing.wikispaces.com/Job+...
47 comments
recommend
bookmark
subscribeDo you really want to delete ?
- within threads
- within tags
- within users
какие у них там игрушки, а
а чо, выглядит солидно
носкуэль, скала, категорные схемки для процессов
так и надо, ящитаю
всячески поддерживаю. давно пора
nosql НЭ НАДА.
That means that queries which would even be impossible to perform with a standard Relational DB, just take a couple of seconds with Bio4j — сообщают нам на сайте
про impossible не верю. В 95% случаев использование nosql является вредом (себе, работодателю, клиентам). Либо по гарантиям, которые от nosql не получить, либо по "неосиляторству" реляционок и превращение модели данных в говно (что потребует тонны времени на поддержку). Впрочем, надеюсь, у них всё будет хорошо — если есть категорное, то и типизация, какая-никакая, да есть.
вот тут как-то обосновывают http://www.slideshare.net/pablo_pareja/b...
благодарю. Буду фтыкать чуть подробнее в это всё.
на самом деле я тут призадумывался недавно
для инфраструктурных дел типизация конечно же ок
но вот непосредственно для моделирования биологии мне кажется оно слишком строгое
живое оно всё практически построено на штуках а-ля парадокс рассела, которые по построению отвергаются типизацией
то есть возможно, там нужно что-то другое, типа контрактов
да вроде не должно быть особо много рассела. А где оно есть? Есть примеры? Тоже подумать хочу.
А контракты — тоже как бы типизация, только в рантайме и иногда "отложенная" (если "post-contract"). Если уж хочется — чего бы и нет. Всегда можно вместо "post-contract" ввести "pre-contract", когда будет определённость. Если нужно, конечно.
спасибо, годная вакансия, но фейл начинается сразу с
>Undergraduate degree in one of: MATHEMATICS, COMPUTER SCIENCE, IT. | ESSENTIAL
по теоркату я знаю только основы самые, а алгоритмов на строках не знаю совсем.
но зато они годных линков накидали хотябы. пиздец, в рашке никогда такой толково написанной вакансии не видел.
ну вам — не нада. вообще для 99,99% достаточно мускула.
а некоторым и масштабируемость нужна.
>neo4j
ну это вообще пушка.
начнём с того, что доступная реализация позволяет только однопоточную запись.
этим можно и закончить, ибо полагаться на то, что какая-то пипиетарная магия что-то там решает, здравый человек не будет.
вообще, есть сильное подозрение что там просто нахуячили каких-то своих, ориентированных на графы, транзакций поверх какого-нибудь kv-store с шардингом, и пытаются это продать (уже лет десять).
вообщем оче смешно видеть в презентации такие слова как very (!) scalable.
но, вполне вероятно, что они предлагают просто там хранить огромную базу с очень низкой конкурентностью на запись, тогда они вообщем-то правы оказываются.
масштабируемость делается и в пределах sql неплохо.
ага, но только на чтение и только с потерей консистентности.
можно вообще dbf-ки rsync-ать, тоже очень неплохо может получиться. в некоторых приложениях.
не только на чтение. С консистентностью тоже можно жить, есть куча различных компромиссов, вплоть до синхронных двухфазных транзакций для адской консистентности.
распределённые транзакции либо люто тормозят либо просто не работают.
фор хум хау. Есть и другие способы сделать нужный уровень консистентности.
какие же есть другие методы кроме транзакций в реляционных бд?
например, можно хранить изменения, выполненные на одной базе, в высокоуровневом виде (не конкретные sql и не конкретные изменения данных, а действия, типа "пользователь создал поддиректорию"), в какой-то таблице, далее эти изменения уже накатывать на остальные базы, с каким-то разрешением конфликтов.
Можно использовать и другие схемы, их есть достаточно, придумать можно ещё больше.
бля, так это и есть отсутсвие консистентности, да, так и делают при использовании всяких kv-стораджей.
это частичная консистентность — реплики, по итогу, когда всё смержат, будут консистентны. Иногда это очень хорошее решение.
Есть и другие схемы — например, несложно пишется "менеджер транзакций" (для постгреса точно, для оракла вроде тоже подобными способами).
Но вот этот подход "все пидарасы, а я дартаньян" мне не очень нравится, поэтому интересно было бы узнать — а что же носикель предлагает для охуенно-ниибической консистентности?
по моему, что-то в том же духе и предлагает, eventually consistent
смысл носикеля же как раз в отказе от мегаконсистентности
да тут как посмотреть. И в реляционках, и в носикеле можно оформить и мегаконсистентность, и eventually consistent transactions, и хоть чорта лысаго. Вот меня и удивил переход мысли в #onsogt/15 , который я увидел как "нам нужна [такая-то] консистентность, поэтому берём nosql".
там помоему чел имел в виду "нам нужна масштабируемость на запись поэтому nosql"
правда хуй знает что такое "масштабируемость на запись" :D
>что же носикель предлагает для охуенно-ниибической консистентности?
лолшто? нихуя конечно же. какбе о том и речь что если всё равно костыли приходится писать, то не лучше ли от неё отказаться например.
и я бы охуенно посмотрел как ты "несложно" пишешь распределённый менеджер транзакций. можешь даже просто примеры написанных привести, мне какраз нужен.
ну пиздец. "нихуя" — оно не всегда приемлемо по условиям задачи. Если "нихуя" приемлемо — бери sql, бери nosql, что угодно, всё будет работать, большие отличия в производительности sql vs nosql не будут заметны, если руки прямые.
Если "нихуя" неприемлемо — вот тут nosql начинает требовать некоторых костылей, тогда как в реляционках есть штатные средства.
штатные средства не масштабируются, поэтому, чтобы самому не костылять eventual консистентность берём nosql, там уже есть.
так что там с менеджером транзакций? нагугли мне хотябы масштабируемый сервис локов.
тебя послушать — так всё возможно.
только похоже что это не так.
например когда хотсет становится размером, который не влезает в одну машину.
ой прям костыли — сделать eventual consistency в rdbms. Учитывай, что консистентность зависит от предметной области, и если nosql предлагает какое-то одно штатное решение, с большой вероятностью оно мне не подойдёт.
Про менеджер транзакций говорить не стал, думал, будет неинтересно. Однако, если настаиваешь... Мне в ближайшее время будет нужен менеджер транзакций для распределённого редактирования графов, хранимых в постгресе. Если готов проспонсировать разработку данного проекта под gpl — можем поговорить. Собственно, из-за привязки менеджера к предметной области и возникает необходимость делать его для каждой задачи отдельно.
Сервис локов гугли сам, мне это неинтересно: ни по затратам времени, ни по применимости нагугленного результата.
про silver bullet никто не говорил.
и ты видимо не понял намёка: ты нихуя не нагуглишь и тем более не напишешь.
хотя напишешь конечно, но совсем не то, что ты тут обещаешь, а очередной никуда не годный говнокостыль.
что ж, время покажет. Если проект дойдёт до реализации — по-любому буду его писать, вариантов у меня не густо. А там и поделюсь впечатлениями.
но, всё же, не нравится мне твой тон речи. Будь попроще штоле.
да, разговор хуёвый какой-то вышел напишу/ненапишу.
ты алгоритм просто опиши да и всё ясно сразу будет.
итак, цель менеджера: адовая консистентность всех реплик sql-сервера.
вот один из вариантов (в специфике постгреса): менеджер обслуживает операции записи, сериализует их внутри себя (грубо говоря, лочит все очереди команд к репликам и срёт туда), отправляет всем репликам команду "выполнить следующие изменения (в простом случае — тупо dml-операторы) и приготовить транзакцию к коммиту" ("prepare transaction" в постгресе), после чего данные сохраняются на диске для последующей фиксации транзакции ("commit prepared"), которая будет запущена менеджером в случае успеха транзакции на всех репликах. Prepared transactions фиксируются быстро.
Можно ещё кучу всего конкретизировать, но отдельным образом, смотря что будет интересно.
централизованный менеджер → не масштабируется.
я думал что распределённые транзакции в постгресе есть изкаробки.
вот ещё можешь глянуть: http://codahale.com/you-cant-sacrifice-p...
> централизованный менеджер → не масштабируется.
Не совсем понял терминологию, слово "масштабирование" используется по-разному. Тут речь про то, что 1. есть дохуя данных и операций с ними, и это надо раскидать на разные хосты, хранящие свою часть данных? 2. есть дохуя хостов, и нужно уметь добавлять ещё?
> я думал что распределённые транзакции в постгресе есть изкаробки.
А я вообще как-то не смотрел на наличие изкаробки, меня бы они не устроили, наверное: например, в случае п.1 из моего вопроса-уточнения про масштабирование. Точнее, на первое время устроили бы, если бы передавали просто изменения данных, но для будущего — навряд ли.
Кстати, я посмотрел ещё подробнее на менеджеры транзакций. Хотя бы для своего удовольствия таки напишу (хотя бы чтобы посмотреть, насколько я лох), но не в самое ближайшее время. Буду публиковать в псачике в том числе.
Статью прочитал. Так и думал, что чистое CAP мало где полезно, если брать C, A, P булевыми, и всегда нужен компромисс, подходящий задаче.
есть дохуя данных и операций и их с каждым днём всё больше, т.е. 1+2.
наличие центрального менеджера транзакций накладывает ограничение сверху на количество операций, что противоречит обоим пунктам.
> 1+2
тут легко делается партиционирование внутри менеджера транзакций — достаточно завести несколько очередей на каждую "партицию" и начинать-завершать транзакции в том числе согласно очередям.
Для добавления хостов тоже кое-что придумывается, но это будет не слишком мгновенным — либо будут однократные перебросы данных, либо "редирект" на новую базу с новыми данными.
если же речь про количество трафика этих операций, то его можно сделать небольшим — передавать только указание, что конкретно нужно изменить.
>партиционирование
очень сильные ограничения на транзакции, добавление хостов — всё совсем непросто становится.
ограничения на транзакции — не очень серьёзные. Про хосты — да, это так. Но разные nosql тоже как-то должны решать добавление хостов, и у них тоже есть либо переброс данных, либо редиректы. А эти штуки — весьма специфические по отношению к предметной области. Поэтому в их ручном кодинге не вижу ничего сверхплохого, хотя и попробую родить что-нибудь более-менее универсальное.
В игрушечных примерах у меня всё заебато получалось, а вот на реальных данных — опять же, буду пробовать, буду отписывать в псто. Очевидно, что говна поем, но, скорее, работать будет прилично.
избыточность+консистентное хеширование → в обычном случае можно обойтись без редиректов, переброс 1/n части данных при добавлении n-ого хоста. так сделано в riak/dynamo. предметная область не при делах.
1/n часть данных получает n-ный хост, да, но разве там нет перебросов между остальными n-1 хостами? Я давно читал про riak, но там, по идее, должны быть. Ошибаюсь? Если да — сообщи, будет интересно поглубже вникнуть в это.
А предметная область в реляционках — таки при делах, потому что реляционка гарантирует отношения между данными, всякие foreign keys. Может какие-то зависимые данные надо перебросить тоже, может нет, а может надо перебросить, заменяя что-то одно на что-то другое. Тут зависит от того, как с ними работают.
просто при добавлении новой ноды данные только в новый хост сливаются. между хостами данные гоняют конечно, при запросах/мап-пердьюсах и при временном выпадении ноды, другие берут на себя её запросы.
почитал подробнее про этот механизм, читал тут: http://wiki.basho.com/Replication.html
"Changing the N value after a bucket has data in it is not recommended. If you do change the value, especially increasing it, you might need to force read repair. Overwritten objects and newly stored objects will automatically be replicated to the correct number of nodes."
Понятно, что при добавлении новой ноды без изменения "N value" нужно только 1/N данных гонять, но часто смысл добавления новой ноды не в надёжности, а в более чоткой параллелизации, потому и надо увеличивать "N value", и гоняться будет не 1/"old N value", а больше.
не, я какую-то хуйню написал. Не в "N value" дело, а в чём-то другом. Но, всё же, проблема есть, и в случаях, когда добавляется новая нода для параллелизации/раскидывания данных по нодам, там не 1/n, жопой чую. Изучу подробнее, отпишу.