Здравствуйте, Gattaka, Вы писали:

G>·>Тебе нужно найти другую работу или предметную область, чтобы с такими крутяками поменьше сталкиваться.
G>Видимо мало я общаюсь в священных войнах. Тут нормальной дискусии не возникает. Обливают гавном с верху до низу.
А ты тут оды всем поёшь, как я вижу.

G>·>Я третий раз спрашиваю — что именно от оракла, где именно и как именно используется?
G>По пресс релизам судит Ну да журналистам виднее
Понятно. По сути сказать нечего.

G>·>Но аналогия всё равно непонятна. Киберакс — программист и решения, в разработку которых он ведёт — покупают технологически развитые компании за большие деньги.
G>Ну молодец на самом деле. Лучше бы он про это на форумах писал. Есть у него хоть один пост с подробностями? Нет!
А зачем это ему? Хочешь — попроси хорошо, может расскажет.

G>Он то в политике сидит, то начинает самоутверждаться в священных воинах. Как то не похоже на миллионера.
Ты ещё и специалист по миллионерам, оказывается.

G>·>Я ничего не хотел в общем-то, я лишь ответил на невежественный вопрос: "Ну а как ты организуешь параллельный доступ без мьютексов?".
G>·>Просто ты так авторитетно заявил о In-Memory OLTP, что я понадеялся, что ты про это хоть что-то знаешь и расскажешь какие-то технические подробности о перформансе. Но кроме пресс-релиза ты видимо ничего не видал, настоящий крутяк.
G>Ты хотел lock-free
Врёшь.

G>я тебе его дал.
Чего-то дал когда не просили, да сам не понял чего и накой.

G>Хочешь знать о скоростях есть специальный стандарт тестирования баз данных,
In-Memory OLTP уже попал в стандарт?

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

Здравствуйте, Gattaka, Вы писали:

G>·>Я киберакса видел, это, кстати, у него не единственный проданный стартап.
G>Ничеси! Автограф взял?
Товарищ "." со мной вместе работал.

G>·>Но аналогия всё равно непонятна. Киберакс — программист и решения, в разработку которых он ведёт — покупают технологически развитые компании за большие деньги.
G>Ну молодец на самом деле. Лучше бы он про это на форумах писал. Есть у него хоть один пост с подробностями? Нет! Он то в политике сидит, то начинает самоутверждаться в священных воинах. Как то не похоже на миллионера.
Ну так на RSDN я только ради того, чтобы провести время захожу. Написать подробнее, в принципе, могу.

G>·>Просто ты так авторитетно заявил о In-Memory OLTP, что я понадеялся, что ты про это хоть что-то знаешь и расскажешь какие-то технические подробности о перформансе. Но кроме пресс-релиза ты видимо ничего не видал, настоящий крутяк.
G>Ты хотел lock-free я тебе его дал.
А где там lock-free? Было бы интересно узнать, как они lock-free хранилище смогли сделать.

Здравствуйте, Sharov, Вы писали:

_>>>Тогда почему гуглопоиск работает не на Oracle? )))
G>>понты
S>Берите круче: за яву обиделись и решили написать свое А так они конечно бы сидели на оракле. Или mssql.
Не пали контору:

SELECT * FROM Internet WHERE text like '%'+query+'%';

Здравствуйте, Cyberax, Вы писали:

G>>Ты хотел lock-free я тебе его дал.
C>А где там lock-free? Было бы интересно узнать, как они lock-free хранилище смогли сделать.
Да наврал он всё, читал (?) книгу и видел ничего.

No locks: The memory-optimized table relies on an optimistic approach to the competing goals of data integrity versus concurrency and high throughput. During the transaction, the table does not place locks on any version of the updated rows of data. This can greatly reduce contention in some high volume systems.

Т.е. обыкновенный MVCC, оптимистичные блокировки. Ну попутал чувак "lock-free algorithms" и "no pessimistic locks", не видит разницу между "database record locking" и мьютексами, похоже.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Sharov, Вы писали:

_>>>>Тогда почему гуглопоиск работает не на Oracle? )))
G>>>понты
S>>Берите круче: за яву обиделись и решили написать свое А так они конечно бы сидели на оракле. Или mssql.
C>Не пали контору:
C>

C>SELECT * FROM Internet WHERE text like '%'+query+'%';
C>

О... палево. Слышал про sql иньекции?

Здравствуйте, Gattaka, Вы писали:

C>>Не пали контору:
C>>

C>>SELECT * FROM Internet WHERE text like '%'+query+'%';
C>>

G>О... палево. Слышал про sql иньекции?
Вот поэтому в Гугле и работает столько инженеров. Они сидят и фильтруют запросы пользователей.

Здравствуйте, ·, Вы писали:

·>

No locks: The memory-optimized table relies on an optimistic approach to the competing goals of data integrity versus concurrency and high throughput. During the transaction, the table does not place locks on any version of the updated rows of data. This can greatly reduce contention in some high volume systems.

·>Т.е. обыкновенный MVCC, оптимистичные блокировки. Ну попутал чувак "lock-free algorithms" и "no pessimistic locks", не видит разницу между "database record locking" и мьютексами, похоже.
Не понятно что тебе не нравится. Ты хотел чтобы блокировок не было — пожалуйста. Тесты производительности? Пожалуйста: TPC-H. Объянить работу? Да просто, при каждом редактировании создается новая версия, куда копируются старые данные и обновляются. Далее есть GC который чистит старые. Все это происходит в оперативке, поэтому быстро.
Насчет lock-free алгоритмов, то да. У меня познания по ним исключительно теоретические. На практике не доводилось использовать. Ибо memory models и прочее делают код менее понятным и сопровождаемым. Я десять раз подумаю чтобы добавлять это в продакшен. В любом случае завести еще дополнительный инстанс, чем обойтись одним инстансом и нагородить lock free алгоритмов. С точки зрения экономии денег такой подход более очевиден. Ведь сопровождение дороже каких-то там вычислительных ресурсов. Главное — простота и понятность кода.

Здравствуйте, ·, Вы писали:

·>А ты тут оды всем поёшь, как я вижу.
Ну почему же сразу всем?

G>>·>Я третий раз спрашиваю — что именно от оракла, где именно и как именно используется?
G>>По пресс релизам судит Ну да журналистам виднее
·>Понятно. По сути сказать нечего.

·>А зачем это ему? Хочешь — попроси хорошо, может расскажет.
А зачем ему о ерунде всякой в политике трындеть? Настоящее развлечение он получил бы если бы сделал классный пост о своей истории успеха. Был бы ажиотаж, пост получил бы 10000 плюсов. И самое главное он получил бы идеи и стимул для дальнейшего развития. Я в этом уверен.

·>Ты ещё и специалист по миллионерам, оказывается.
Сам от себя не ожидал.

·>Врёшь.
Это грязная инсинуация!

·>In-Memory OLTP уже попал в стандарт?
Стандарт всегда будет отставать на 10 лет. Все используют узкоспециализированные фичи конкретных СУБД. Никто не пользуется этим вашим стандартом. Это все фантазии, что на стандартной фигне можно что-то стоящее сделать.

·>Короче, спорол очередную чушь, и предлагаешь оппоненту поискать доказательства. Слишком зелено, в обоих смыслах.
У тебя еще вопросы технические остались? Может не понятно что-то? Как код правильно писать ну и в таком духе. Спрашивай!

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, ·, Вы писали:

G>·>

No locks: The memory-optimized table relies on an optimistic approach to the competing goals of data integrity versus concurrency and high throughput. During the transaction, the table does not place locks on any version of the updated rows of data. This can greatly reduce contention in some high volume systems.

G>·>Т.е. обыкновенный MVCC, оптимистичные блокировки. Ну попутал чувак "lock-free algorithms" и "no pessimistic locks", не видит разницу между "database record locking" и мьютексами, похоже.
G>Не понятно что тебе не нравится. Ты хотел чтобы блокировок не было — пожалуйста.
Ты начал про мьютексы. MMVCC означает остуствие блокировок записей, но ничего не говорит об обсутствии блокировок тредов на мьютексах. В мире low latency — блокировка на мьютексе горячего треда — смерти подобна.

G>Тесты производительности? Пожалуйста: TPC-H. Объянить работу? Да просто, при каждом редактировании создается новая версия, куда копируются старые данные и обновляются. Далее есть GC который чистит старые. Все это происходит в оперативке, поэтому быстро.
О MVCC я уже писал, наконец-то MSSQL стал это поддерживать. Тесты показывают "количество запросов в час", иначе говоря high throughput. Какое это имеет отношение к low latency? Там важна latency histogram. По сути важно это — за какое максимальное время выполняется каждый отдельный запрос.

G>Насчет lock-free алгоритмов, то да. У меня познания по ним исключительно теоретические. На практике не доводилось использовать. Ибо memory models и прочее делают код менее понятным и сопровождаемым. Я десять раз подумаю чтобы добавлять это в продакшен. В любом случае завести еще дополнительный инстанс, чем обойтись одним инстансом и нагородить lock free алгоритмов. С точки зрения экономии денег такой подход более очевиден. Ведь сопровождение дороже каких-то там вычислительных ресурсов. Главное — простота и понятность кода.
Тут дело не в сопровождаемости, а в реализации бизнес-требований. Если требуется максимальное время отклика 1ms, то думай/не думай, но в продакшн это придётся добавлять, других вариантов тупо нет.
Дополнительный инстанс завести не всегда возможно. Скажем, валютная пара EUR/USD самая торгуемая, ~90% всего трафика. Параллелить на инстансы нельзя, таковы бизнес-требования — все заявки прут в один стакан (order book).

Здравствуйте, ·, Вы писали:

·>Здравствуйте, Gattaka, Вы писали:
·>Ты начал про мьютексы. MMVCC означает остуствие блокировок записей, но ничего не говорит об обсутствии блокировок тредов на мьютексах. В мире low latency — блокировка на мьютексе горячего треда — смерти подобна.
Нет, не я. Нужный начал. Ну про блокировку сейчас даже студенты знают thread sleep и все такое.

G>>Тесты производительности? Пожалуйста: TPC-H. Объянить работу? Да просто, при каждом редактировании создается новая версия, куда копируются старые данные и обновляются. Далее есть GC который чистит старые. Все это происходит в оперативке, поэтому быстро.
·>О MVCC я уже писал, наконец-то MSSQL стал это поддерживать. Тесты показывают "количество запросов в час", иначе говоря high throughput. Какое это имеет отношение к low latency? Там важна latency histogram. По сути важно это — за какое максимальное время выполняется каждый отдельный запрос.

G>>Насчет lock-free алгоритмов, то да. У меня познания по ним исключительно теоретические. На практике не доводилось использовать. Ибо memory models и прочее делают код менее понятным и сопровождаемым. Я десять раз подумаю чтобы добавлять это в продакшен. В любом случае завести еще дополнительный инстанс, чем обойтись одним инстансом и нагородить lock free алгоритмов. С точки зрения экономии денег такой подход более очевиден. Ведь сопровождение дороже каких-то там вычислительных ресурсов. Главное — простота и понятность кода.
·>Тут дело не в сопровождаемости, а в реализации бизнес-требований. Если требуется максимальное время отклика 1ms, то думай/не думай, но в продакшн это придётся добавлять, других вариантов тупо нет.
·>Дополнительный инстанс завести не всегда возможно. Скажем, валютная пара EUR/USD самая торгуемая, ~90% всего трафика. Параллелить на инстансы нельзя, таковы бизнес-требования — все заявки прут в один стакан (order book).
Ну вот я тебе и говорю, что таких систем 0.1% от общего числа. Ты ведь сам это все подтверждаешь.

Здравствуйте, Cyberax, Вы писали:

C>Ну так на RSDN я только ради того, чтобы провести время захожу. Написать подробнее, в принципе, могу.

Я думаю это многим было бы интересно

Здравствуйте, alex_public, Вы писали:

_>Аналогичная ситуация и с СУБД. Есть множество ситуаций, когда классические СУБД не будут справляться с работой.

Все начинается намного раньше. Достаточно одного раза чтобы оптимизатор слажал (а лажает он таки довольно часто даже у большой тройки, про всякий постгри я даже не говорю), и все, без понимания алгоритмов работы оптимизатора и того как хранение и чтение данных устроено ты приплыл — сразу же возникают рассчеты зарплаты по часу да чтение логов в 300ГБ.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>у да чтение логов в 300ГБ.

Блин я так и знал что в этом оптимизатор виноват. Скажите, а русские хакеры этот оптимизатор придумали?

Здравствуйте, Gattaka, Вы писали:

_>>Если ты говоришь про своё первое сообщение, то оно вполне адекватное. И как раз поэтому большинство коллег начало нормально на него отвечать — в начале темы была вменяемая техническая дискуссия. Однако потом ты начал выдавать всяческие глупости, на которые даже странно было отвечать, а можно было только посмеяться. Я говорю про высказывания в стиле "программистам не надо знать алгоритмы". Причём ты это обосновывал тем, что неразумно писать везде свои велосипеды, вместо использования готовых реализаций (в общем то правильная мысль сама по себе). Так вот это как раз жалкая попытка подмены понятий, потому как знать алгоритмы надо не только для написания своих реализаций, но и для правильного выбора из готовых.
G>Обычный заднеприводный программист. Надо говорить все точно, сарказм, намеки, второй смысл. Это ничего не понимает. Все понимает только буквально. Ничего не поделаешь, издержки профессии. Буквально травма. От себя могу порекомендовать познакомиться с методами Монте Карло. Понимание сути их работы спасает в данном случае.

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

G>>>Нет таких ситуаций. Классические СУБД непобедимы.
_>>Тогда почему гуглопоиск работает не на Oracle? )))
G>понты

Здравствуйте, alex_public, Вы писали:

Моя интерпретация вопросаМой интерпретатор языка невольно создаёт в голове картину: раз, мы тут хэштаблицу вставили (и она вполне подходит), а потом сидим-сидим и вдруг подумали — да тут же лучше двоичное дерево! Разумеется такого не происходило, т.к. это ещё надо как-то доказать, что оно (двоичное дерево) лучше. С другой стороны, если данные изначально "деревянные" — то и вопроса о хэш-таблице не стоит. Поэтому, и мой выбор — "Нет, такого не происходило.". Но это не значит, что двоичное дерево это какое-то зло. Кроме того, если бы скажем в шарпе за Dictionary скрывалась хэш-таблица с открытой адресацией — то я бы почти никогда и не использовал её, хотя сам алгоритм в некоторых случаях даёт наилучшие результаты и отлично масштабируется или довольно просто делается lock-free. Кстати про lock-free тоже вопрос интересный можно сочинить... "как часто вы сидели-сидели а потом решили, блин, да тут нужна lock-free hash-table?".

PS: Я ещё неделю назад хотел написать уточнение, но удержался. Сегодня нет.

Здравствуйте, Mystic Artifact, Вы писали:

MA>Здравствуйте, alex_public, Вы писали:

MA>Моя интерпретация вопросаМой интерпретатор языка невольно создаёт в голове картину: раз, мы тут хэштаблицу вставили (и она вполне подходит), а потом сидим-сидим и вдруг подумали — да тут же лучше двоичное дерево! Разумеется такого не происходило, т.к. это ещё надо как-то доказать, что оно (двоичное дерево) лучше. С другой стороны, если данные изначально "деревянные" — то и вопроса о хэш-таблице не стоит. Поэтому, и мой выбор — "Нет, такого не происходило.". Но это не значит, что двоичное дерево это какое-то зло. Кроме того, если бы скажем в шарпе за Dictionary скрывалась хэш-таблица с открытой адресацией — то я бы почти никогда и не использовал её, хотя сам алгоритм в некоторых случаях даёт наилучшие результаты и отлично масштабируется или довольно просто делается lock-free. Кстати про lock-free тоже вопрос интересный можно сочинить... "как часто вы сидели-сидели а потом решили, блин, да тут нужна lock-free hash-table?".

MA>PS: Я ещё неделю назад хотел написать уточнение, но удержался. Сегодня нет.
Я так и подумал что такой интерпретатор найдется.

Здравствуйте, Gattaka, Вы писали:

G>Я так и подумал что такой интерпретатор найдется.
Раз ты такой предусмотрительный — почему не учёл этого в формулировании своего вопроса?

Здравствуйте, rameel, Вы писали:

C>>Ну так на RSDN я только ради того, чтобы провести время захожу. Написать подробнее, в принципе, могу.
R>Я думаю это многим было бы интересно
Ок, напишу статью.

Здравствуйте, Mystic Artifact, Вы писали:

MA>Здравствуйте, Gattaka, Вы писали:

G>>Я так и подумал что такой интерпретатор найдется.
MA> Раз ты такой предусмотрительный — почему не учёл этого в формулировании своего вопроса?
Почему же? Предусмотрел. Я планировал глумится над их программерской наивностью и прямолинейностью в ответ на их посты.

Здравствуйте, Gattaka, Вы писали:

G>>>Я так и подумал что такой интерпретатор найдется.
MA>> Раз ты такой предусмотрительный — почему не учёл этого в формулировании своего вопроса?
G>Почему же? Предусмотрел. Я планировал глумится над их программерской наивностью и прямолинейностью в ответ на их посты.
Что-то мой интерпретатор сдался.

PS: Вроде в тему: буквально на днях из цикла выкинул построение "словаря" (не суть важно, что это) заменив на обычную фильтрацию... и метод вместо 10 секунд молочения стал делать работу меньше секунды. Понятно, что это из области "кто-то заработался и всунул ерунду", но если утрировать то можно сделать вопрос: "Как часто в реальных, рабочих проектах вы говорили: "Неее... здесь лучше вообще не использовать хэш таблицу или двоичное дерево". И это было действительно необходимо."