juan_gandhi | студент и основоположник (басня в прозе)

студент и основоположник (басня в прозе)

Широко известна в народе так называемая бигтейбл, внедрённая в дискурс гуглом. Что за бигтейбл такой? Это пакеты данных, индексированные ключом; ключ - строка неограниченной длины. Пакет не обязательно читать-писать целиком, он состоит из групп колонок, так что целиком читается-пишется только группа; группа состоит из колонок. В каждой ячеечке (ключ + колонка) хранится какое-то данное; можно по желанию хранить и историю, т.к. к данному приложена отметка времени; юзер сам выбирает, хранить последнюю или всё что есть.

Удобно, быстро, дёшево; да ещё и распределять данные легко: фактически таблица состоит из таблеток, содержащих определённую часть ключей (смежную); таблетки ж разбросаны по серверам. Репликация тоже делается без участия человека.

Одно неудобство - всё это на си, и работает через арписи. Сишникам раздолье, у них есть соответствующие классы; а джавщики страдали. Наконец выдающийся основоположник Ф.Е. осчастливил население, написав джавный интерфейс; программист судьбу благословил.

В это время в Сингапуре учился студент Маниш, родом из индийской деревни. В Сингапуре учёба, как в СССР, халявная, только потом надо три года отработать как молодому специалисту. А работа в Сингапуре одна: в банке потеть над банковским софтвером.

Но есть же Гугл; и вот Маниш посылает своё резюме, чтоб приехать практикантом.

В Гугле с практикантами порядок такой: все эти левые резюме сваливаются в базу; их там десятки тысяч; желающие инженера копаются в этой базе и иной раз лениво выдёргивают какой-нибудь пёрл (всё та же Пирамида Лебедева), и отправляют на доследование, т.е. в кадры. Кадры организуют телефонные интервью, ну и т.д. Обычно на этом и кончается: спросишь у будущего практиканта, может ли он запрограммировать Фибоначчи на каком-либо языке, он и вянет. Маниш не отвял, а браво ответил на все вопросы и осенью явился в Маунтин Вью.

Как это осенью? А так: кроме летней, бывает ещё зимняя практика, на два семестра. Ну там сначала-то он записался на один семестр, но вскоре это переиграл. Да и то; зарплаты в гугле практикантам плотят больше иной раз, чем инженерам в стартапах в Пало Альто. Так что у меня завёлся весёлый умный практикант. Быстренько освоил язык питон, а также гугловский стиль джавы.

А нам как раз об это время шибко надоел майсиквел, на котором вся трансляция держится. Надо было бы, конечно, просто добавив серверов, но кто же даст компьютер (один!) на такое пустяковое дело как перевод сотни с лишним проектов на сотню с лишним языков! Растрата одна... этак на кофейную машину ценой в 11 штук денег не останется.

А бигтейбл можно деплоить на бигтейбловых серверах, и им, бигтейбловцам, типа не жалко (им же рапортовать, мол, ещё сто гигабайт добавили, ура). Так что, с двойной репликацией, мы получили практически шесть машин под наши таблицы. Маниш стал, естественно, портировать данные с майсиквела, и рисовать джавный доступ.

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

И что Маниш? А Маниш обнаруживает такую простую вещь: если у нас таблица разбита на 20 таблеток, и вся информация, где какие ключи, известна, то почему бы нам в 20 threadов не читать эту самую таблицу, со всех таблеток параллельно. И пишет Маниш такую параллельную читалку.

Дело в том, что это особенность джавы - лёгкость, с которой ты пишешь multithread code. В си сдохнуть можно такое написать.

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

Пишем ченджлист, посылаем ему на ревью.

Тишина. Две недели - ни слова.

Пишем Вежливое Письмо.

Тишина. Две недели, тишина.

Пишем ещё письмо. В ответ нам сообщают, что а) надо ещё разобраться; б) есть недоработки; в) мы сами над аналогичным вопросом думаем.

И так мы провели оставшиеся полгода. Пока Маниш не уехал обратно в Сингапур.

Потом я ещё три месяца надоедал основоположнику. Потом я пошел в другую команду. В той, предыдущей, все эксперименты с бигтейблом выкинули на помойку. Включая, очевидно, и код Маниша.

Так что воз и ныне там.

А Маниш нормально; полученной в Гугле зарплатой он расчитался с Сингапуром и поехал в Цюрихское отделение Гугла, на постоянку. И ныне там; катается на лыжах, сделал себе модную татуировку. Думаю, у него всё хорошо.

Но Гугл так и не умеет читать бигтейблы параллельно.

Flat | Top-Level Comments Only

Гугл всё равно лучше.

Чем лучше?

чем армян.

Он индексирует мой сайт, а Яндекс - нет.

http://webmaster.yandex.ru/

Бесполезно. Я пробовала уже.

Значит за эротику банят. А у Гугла может просто руки до рунета не дотянулись.

Гуглу русское пофиг, имхо; у них есть словарь неприличных русских слов, а больше, наверное, всё.

Но Кашане я б советовал не обсуждать такие вопросы в открытом месте, т.к. нас тут читают; вдруг кто-нибудь возьмёт да и проявит инициативу - для этого много не надо.

Я все-таки справедливости ради замечу, что
а) не гугл придумал "индексацию ключом"
б) это не совсем индексация ключом, это столбцовые базы данных (column-oriented databases).
Вместо кортежа (n-tuple) (f1, f2, ... ,fn) хранятся различные проекции этого кортежа (в том числе с переставленными атрибутами). Фишка в том, что эти проекции проще индексировать, сжимать и быстро находить.

Кортежи, конечно, чисто мысленное построение.

Как и вся математические абстракции.

как-то сложно у вас в гугле бегтейбл объясняется..
обычно пишут "столбцовые базы данных". куда понятней :)

Я про "столбцовые базы данных" ничего до сегодняшнего дня не слышал. :)

Под "столбцовыми базами данных" (vertical store, еще как то) обычно имеют в виду реляционки типа Sybase AQ, Monet DB

Бигтейбл - обычно называют key-value store

Сдаётся мне, что для человека, так не любящего совок, Вы слишком наплевательски относитесь к NDA.

А он разве в Гугле работает?

А Гугл это вообще что?

Это такое слово с разноцветными буквами и желтыми «о».

Так бигтейбл же это открытая информация.

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

Если будут претензии, я переведу этот пост в режим для френдов.

To be fair, это скорее нехарактерный случай. Я с основоположниками особо не сталкивался (а когда сталкивался, получал быстрые ответы), но я могу себе представить, какое количество code reviews им приходит. Если человек через день-два не отвечает, обычно или толкаешь его коллег, или идешь к нему вживую или в чат, и там все быстро решается - или он понимает, зачем тебе это нужно, или ты понимаешь, почему это никому не нужно. Конечно, если целенаправленно ни с кем больше не говорить, а ждать формального ответа, у code review есть шанс протухнуть.

Полухарактерный. Бывало так, бывало и так. Однажды от Джоша Блока, вполне интеллигентного и покладистого человека, я так и не дождался ревью, но не больно и надо было. А так - все люди разные, конечно. И, несмотря на все эти глюки, я этих основоположников очень уважаю, даже если у нас взгляды радикально расходятся.

В том месте, где я сейчас работаю, вообще нет документации по интернал интерфейсам. Совсем вообще ни одной и это ужасно. Зато у каждого сотрудника есть телефон, также есть сает с приятной табличкой с именами-фамилиями-фотками-телефонами-дислокацией, так что довольно быстро научаешься звонить, узнавать, а если что сложно, то узнавать, можно ли подойти, и подходить. И как-то так получается, что этот ужасный фейл, отсутствие документации, на самом деле приводит к неиллюзорным винам, в том смысле, что если мне что-то от кого-то нужно, то я не буду сидеть месяц занимаясь другими делами, я встану и пойду к нему и поговорю. Ну, потому что это принятый способ взаимодействия -- пойти и поговорить.

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

Про "убиться можно" - наглая ложь.

Вы про многопоточность?
ДУмаете библиотеки заменяют родную поддержку в языке (со всей оптимизацией и пр)?

А что там можно особо оптимизировать? Вот разве что стек сделать в виде списка.

так в Яве сообществе они этим занимаются с 90х
лок стратегии или общение процессора с локальными кешами на многоядерных архитектурах

Лок стратегии везде одинаковы. Разве что в Джаве блокировки сделаны с кривизной. Общение процессора с локальными кэшами - тоже везде аналогично, и применимо только к кривым архитектурам типа сановской, в которых на железе сэкономили. В более приличных архитектурах типа интеловской оно делается в железе и потому может работать гораздо эффективнее.

Лок стратегии везде одинаковы. Р

Я помню ИБМ много работала над локами в вирт машине и они писали, что достаточно сильно повышают перформанс

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

в смысле простые явовские программы лучше масштаб их аналогов на С++

вс еэто были какие-то простые примеры

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

volatile bool flag;
int something = 0;
...
flag = 0;
something = 10;
sleep(1000);
if (flag)
{
   if (something == 20)
   {
       doSomething();
   }
}

гарантирует вам, что тело ифа может исполниться вообще, то вы глубоко заблуждаетесь, ололо. Это в сишарпе assignment to a volatile memory location acts as a memory barrier, preventing relocation of reads and writes from/to ANY memory locations to be cached by the compiler. А в жаве как нефиг - something не volatile, значит, можно её зачитать в регистр вначале функции и больше не трогать никогда.

* assignment to or a read from

s/to be cached/to be performed/
О чём-то не о том я думал

а ну этот конкретно пример интеракции оптимизации компилятора и многопот известен давно
Они с ним что-то сделали или все также?

В жаве? Не знаю, подозреваю, что нет.

В сишарпе такие майндфаки исправляются - например, была совершенно прекрасная в своей глючности вещь: finalizer объекта мог быть вызван по ходу исполнения метода этого объекта, если там дальше ни разу не использовался this. То есть если я зачитываю вендовую Handle в локальную переменную и собираюсь с ней дальше что-нибудь сделать, то где-то посередине может случиться сборка мусора, которая замечательно соберёт тот объект, в котором сейчас исполняется код (ну, раз он не обращается ни к каким полям уже, всё нужное сохранено в локальных переменных), вызывается деструктор, закрывающий хэндл, и мой метод замечательно сосёт всякое. Реальный пример: я пишу метод Close для свого файлообразного потока, ну, понятно.

То есть проблема была в том, что IntPtr, использовавшийся для ссылок на объекты оси, нифига не понимался GC как ссылка. Это исправли добавлением классов вроде SafeHandle. Исправили! А не как в жаве!

> В жаве? Не знаю, подозреваю, что нет.

прекрасный аргумент

то что обсуждается выше - действительно неприятный баг в понимании волатайл явой

в чем состоит баг? то о чем вы говорите исправлено лет 6 назад. не говоря уже о том что бага никогда не было, все соотвествовало спекам. просто в 1.5 решили volatile немного затянуть.

какая то чушь, уж извините

Это в сишарпе assignment to a volatile memory location acts as a memory barrier, preventing relocation of reads and writes from/to ANY memory locations to be cached by the compiler.

Вот это-то как раз и есть майндфак, как и многое у M$.

Забавно получилось.

Оказывается, я был не прав, в пятой жаве таки сделали всё как в дотнете (там есть ещё какие-то совсем дико суровые тонкости в дотнетовской имплементации, но неважно).
http://en.wikipedia.org/wiki/Java_Memory_Model
http://www.javamex.com/tutorials/synchronization_volatile_java_5.shtml
http://java.sun.com/docs/books/jls/third_edition/html/memory.html

Но зато как весело теперь ваш комментарий выглядит!

Да, да, отлично, теперь это вопрос для собеседований!

И мой комментарий следует читать так:

"...как и многое у M$ и Sun".

Да нет же, это как раз правильный подход именно к мультитредовой синхронизации.

Слово volatile в C и C++ имело несколько другой смысл и для другого предназначалось - для прямой работы с железом, например. Ну и вот компилятор гарантирует, что каждое чтение-запись дойдёт до железа, и что относительный порядок волатильных чтений/записей будет как в коде (а все остальные чтения/записи могут прыгать как угодно вокруг, если это не меняет семантику).

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

Но это и неудобно программисту (легко что-нибудь забыть так пометить, а проверить никак невозможно), и как правило тормозит по сравнению с новой, заточенной специально под мультитредное взаимодействие концепцией: когда каждый синхронизационный примитив именно что синхронизирует всё состояние. Memory barrier ведь ничего не делает на самом деле, это просто запрет компилятору производить некоторые оптимизации. Зато позволяет проводить другие. В самом деле, вот есть у меня захват и освобождение мутекса, в новой модели компилятор не сможет перенести какие-то операции через эти два момента (причём скорее всего тех операций, которых я бы хотел разрешить перенести, не будет вовсе, например, потому что локальные переменные функции другим тредам недоступны по определению и на них запрет не распространяется), зато сможет как угодно тасовать и кешировать их внутри этих трёх кусков.

Да нет же, это как раз правильный подход именно к мультитредовой синхронизации.

Я почитал первую и третью ссылку и понял (вторую ссылку я читал как-то давно, но понял совсем не то, что понял сейчас).

Слово volatile в C и C++ имело несколько другой смысл и для другого предназначалось - для прямой работы с железом, например.

К этому и претензия - почему в современной Java тоже есть "volatile", а не какое-нибудь там что-нибудь, я не знаю.
Это весьма запутывает.
На самом деле, речь ведь идет об определении блоков, связанных отношением happened-before.

Вполне типичная история. Студент полез поперёд батьки, который вдобавок ещё и "Основоположник".

А сами разве не можете пользоваться кодом? Почему на это требуется соизволение верховного Основоположника?

Сами, конечно, пользовались - пока все не разбежались. После чего было предано забвению.

Я, на самом деле, пару раз смог добиться благосклонного одобрения моего кода основоположником - но в моём коде не было такой наглой эффективности, как у Маниша.

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

Я, когда имею дело с новой фирмой, запускаю несколько пробных шаров, вроде маняшиного кода, и жду. Если вижу, что "идет", сделаю все, что могу, и даже больше. Но если моя инициатива никому не нужна (или хуже - наказуема), строю свои дальнейшие отношения с работодателем по принципу "сделаю все, что скажешь, но не более того". Надо сказать никогда никаких конфликтов или непонимания с "их" стороны не было.

Какой вы меркантильный, есть еще люди, для которых это все еще just fo fun.

Это не меркантильность. Это нежелание чувствовать себя идиотом. Что же касатся fun - у меня это на рабочие отношения не распространяется. Так сложилось - не фан.

Ну, так неинтересно жить. Хочется ж прекрасного. Если я попадаю в такое положение, что надо трубить от и до, то это означает одно: нужно срочно менять работу. (Как и вышло с гуглом.)

Понимаю. Но у меня "жить" и "работать" находятся в несколько разных плоскостях. Может, мне не повезло, но за те виды деятельности, которые мне по душе, денег не платят. Во всяком случае таких, на которые можно жить. Поэтому мне приходится зарабатывать тем, за что более или менее прилично платят, и что не требует слишком много времени и усилий. Т.е. я бы рад работать ради удовольствия, но не знаю такой работы. Как-то так.

Угу. Или стараться всё делать правильно или — халтура и работа 9-to-5. Остальное — компромиссы с самим собой.

Ох уж этот «Гугл».

Давайте про GPS теперь :-)

Дело в том, что это особенность джавы - лёгкость, с которой ты пишешь multithread code. В си сдохнуть можно такое написать.
Посмеялся, спасибо.

А история хорошая.

Поясню про Си: там такое или нельзя написать вообще (потому что нет memory model) или пишется так же легко как в Java — Всё зависит от вашей точки зрения на правильность работы :)
В 99.9% случаев — второе.

Java не предоставляет ничего интересного для мультитреда, кроме (это важно, это очень важно, но не всегда) memory model. А так — те же локи, те же треды. Всё. Никакого rocket science вообще, увы.

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

Flat | Top-Level Comments Only

студент и основоположник (басня в прозе)

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject