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

G>>>Якобы не тянущие СУБД в 99% означает не тянущих программистов, которые ничего по этим СУБД не читали.
G>·>Или не в 99%, а в 9.9%... Но с тем что таки бывают ситуации, когда СУБД не тянут — спорить, надеюсь, не будешь?
G>В каких? Давай конкретнее разберем твои случаи.

Давай.
Возьмём, насколько я понял, близкий к тебе пример — исходники TensorFlow. В нём массово и многократно используется std::map (unordered_map, кстати, тоже). Ты предлагаешь все эти мапы заменить на запросы в БД. Так?
Какую СУБД использовать?

G>·>Не понял. Какая взаимосвязь между СУБД и бинарным деревом? СУБД это тип приложения/библиотеки. А бинарное дерево — абстрактная структура данных. Как ты так апельсины на яблоки ловко заменяешь?
G>Потому что не знаешь как эти СУБД устроены внутри. Это всего лишь шедевральная композиция элементарных алгоритмов о которых ты читал у Кнута. Она автоматически все делает даже думать не надо.

У СУБД множество накладных расходов на обеспечение транзакций и других требований именно к БД. Что не нужно в большинстве приложений, которые просто данные в памяти хранят и ими пользуются. Ты этого не понимаешь? Для минимального понимания проблемы можно просто к каждой переменной в программе добавить свой мьютекс и получать доступ исключительно через него. Как думаешь, станут ли программы быстрее?

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

N>Давай.
N>Возьмём, насколько я понял, близкий к тебе пример — исходники TensorFlow. В нём массово и многократно используется std::map (unordered_map, кстати, тоже). Ты предлагаешь все эти мапы заменить на запросы в БД. Так?
N>Какую СУБД использовать?
Конечно нет! Tensorflow как раз относится к тому 0,1% систем где все законно и нужно. Это как раз то что избавляет программы, использующие Tensorflow думать о map или не map. Как раз очень хороший, показательный пример. Пользователи Tensorflow думают о бинарных деревьях?
Как много из здесь присутсвующих программистов писали что-то похожее по нагрузке и абстракции? Единицы, если вобще кто-то. Зато задумывались о применении бинарных деревьев более 50%. Вопрос почему? Да потому что надо было хоть где-то применить эти знания. В итоге имеем говнокод там где можно было бы обойтись без него.

N>У СУБД множество накладных расходов на обеспечение транзакций и других требований именно к БД. Что не нужно в большинстве приложений, которые просто данные в памяти хранят и ими пользуются. Ты этого не понимаешь? Для минимального понимания проблемы можно просто к каждой переменной в программе добавить свой мьютекс и получать доступ исключительно через него. Как думаешь, станут ли программы быстрее?
А ты используй read uncommited.

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

N>>Давай.
N>>Возьмём, насколько я понял, близкий к тебе пример — исходники TensorFlow. В нём массово и многократно используется std::map (unordered_map, кстати, тоже). Ты предлагаешь все эти мапы заменить на запросы в БД. Так?
N>>Какую СУБД использовать?
G>Конечно нет! Tensorflow как раз относится к тому 0,1% систем где все законно и нужно. Это как раз то что избавляет программы, использующие Tensorflow думать о map или не map. Как раз очень хороший, показательный пример. Пользователи Tensorflow думают о бинарных деревьях?

Tensorflow — 934 контрибьютора! И это только открытых, не все возвращают изменения в проект. Это опенсорс, пользователи заглядывают к нему в исходники и меняют их. А если и не меняют, то смотрят, как устроено, как работает, портируют под свои платформы. Тут нет такого: взял и пользуйся. И так в большей части библиотек.
Позволь мне усомниться в обширности твоего опыта.
OpenCV — также, даже я со своей непритязательностью попадал когда-то в контрибьюторы.
ffmpeg — течёт, документации мало или нет, приходится постоянно лазать по исходникам.
Это всё такие фундаментальные библиотеки в своих отраслях.
Да даже boost, stl, Qt — везде приходится лазать и иногда править.
Нигде нет такого: готово, работает, только пользуемся.

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

N>>У СУБД множество накладных расходов на обеспечение транзакций и других требований именно к БД. Что не нужно в большинстве приложений, которые просто данные в памяти хранят и ими пользуются. Ты этого не понимаешь? Для минимального понимания проблемы можно просто к каждой переменной в программе добавить свой мьютекс и получать доступ исключительно через него. Как думаешь, станут ли программы быстрее?
G>А ты используй read uncommited.
Ты серьёзно?!!

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

N>Нигде нет такого: готово, работает, только пользуемся.
934 контрибьютера/ 62485 звезд = 0.014947. Какая потрясающая точность! И это при том что далеко не все ставят звезды, но все равно пользуются. В рамках всей отрасли 934 контрибютера это как раз те ребята, которые по делу используют бинарные деревья и они знают что они делают. Но посмотрите на голосование здесь на этом форуме. Где про tensofrflow слышало ровно 2,5 человека. Более половины программистов куда умудрились втроить бинарные дереьвя. Куда? По делу или просто так? Никто не знает, т.к. реальные примеры никто не приводит.

N>Ты серьёзно?!!
Ну а как ты организуешь параллельный доступ без мьютексов? Используй табличные переменные тогда. Вариантов масса на самом деле.

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

G>·>Чтобы правильно выбирать абстракции высокого уровня надо представлять как они имплементированы, чтобы понимать область их применимости и представлять себе последствия их применения.
G> Хорошо реализованная абстракция освобождает от этого.
Гы. Наивный юноша.

G>>>·>Или не в 99%, а в 9.9%... Но с тем что таки бывают ситуации, когда СУБД не тянут — спорить, надеюсь, не будешь?
G>>>В каких? Давай конкретнее разберем твои случаи.
G>·>Low Latency.
G>
Ну почитай что-ли Интернет, если слова незнакомые.

G>·>Гм.. любопытно. В какой из СУБД реализовано, скажем, бинарное дерево?
Так в какой?

G>·>В любом случае, помимо реализации этих алгоритмов там есть ещё много чего, что не всегда нужно, но создаёт оверхед, который не тянет.
G>·>Заточенная и оптимизированная под конкретную задачу имплементация алгоритма может оказаться на порядки эффективнее, чем попытка прикрутить универсальную имплементацию.
G>Это какой-то разговор в стиле "а вы станьте ежиками". Давай конкретику обсудим. Желательно с кодом.
Ещё более конкретно, ну например, FX orderbook. Ты правда её в субд запихивать собрался?!!

N>>Нигде нет такого: готово, работает, только пользуемся.
G>934 контрибьютера/ 62485 звезд = 0.014947. Какая потрясающая точность! И это при том что далеко не все ставят звезды, но все равно пользуются. В рамках всей отрасли 934 контрибютера это как раз те ребята, которые по делу используют бинарные деревья и они знают что они делают. Но посмотрите на голосование здесь на этом форуме. Где про tensofrflow слышало ровно 2,5 человека. Более половины программистов куда умудрились втроить бинарные дереьвя. Куда? По делу или просто так? Никто не знает, т.к. реальные примеры никто не приводит.
Я не понял к чему эта статистика. Да, есть куча формоклёпов, некоторым и страшное слово "хеш-таблица" знать не надо — кинул кнопку на форму и оно как-то работает, считает зарплату 45 минут... А кто-то забивает на СУБД и кнопочки и делает на этом $20M-$50M. И что это по-твоему доказывает?

N>>Ты серьёзно?!!
G>Ну а как ты организуешь параллельный доступ без мьютексов? Используй табличные переменные тогда. Вариантов масса на самом деле.
О, боже! Ну например, lock-free algorithms, слыхал?
В конце концов, от параллельного доступа в коде можно вообще иногда избавиться.

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

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

G>>·>В любом случае, помимо реализации этих алгоритмов там есть ещё много чего, что не всегда нужно, но создаёт оверхед, который не тянет.
G>>·>Заточенная и оптимизированная под конкретную задачу имплементация алгоритма может оказаться на порядки эффективнее, чем попытка прикрутить универсальную имплементацию.
G>>Это какой-то разговор в стиле "а вы станьте ежиками". Давай конкретику обсудим. Желательно с кодом.
·>Ещё более конкретно, ну например, FX orderbook. Ты правда её в субд запихивать собрался?!!
На мосбирже оракл. Все прекрасно работает.

·>Я не понял к чему эта статистика. Да, есть куча формоклёпов, некоторым и страшное слово "хеш-таблица" знать не надо — кинул кнопку на форму и оно как-то работает, считает зарплату 45 минут... А кто-то забивает на СУБД и кнопочки и делает на этом $20M-$50M. И что это по-твоему доказывает?
Опять же приведу пример Усманова, который владеет Mail.Ru, а также является самым богатым человеком в России. Он в обще программировать не умеет. Давай у него про СУБД спросим?

N>>>Ты серьёзно?!!
G>>Ну а как ты организуешь параллельный доступ без мьютексов? Используй табличные переменные тогда. Вариантов масса на самом деле.
·>О, боже! Ну например, lock-free algorithms, слыхал?
·>В конце концов, от параллельного доступа в коде можно вообще иногда избавиться.
А ты слышал про In Memory OLTP. Знаешь как оно работает. Почитай если не знаешь. Применительно к твоей реплике будет полезно. Я серьезно без стеба. Если не знаешь, то надолго запомнишь.

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

G>Потому что ты не слушаешь аргументов, а занимаешься быкованиями. В силу своих каких-то комплексов. Еще раз. В большинстве случаев можно и НУЖНО самое главное обходится стандартными библиотеками и либами. Не надо каждый раз реализовывать свою СУБД, если таковых уже полно. Следовательно задача выбора между деревом и хешем возникает настолько редко, что ей должны заниматься 0,01% программистов. На практике это 50% программеров, что происходит преимущественно из-за желания показать знание алгоритмов и хоть где то их применить. Даже если можно обойтись без них. В итоге получаем говнокод.

У тебя во всей этой теме наблюдается попытка классической подмены понятий. Ты постоянно пытаешься поставить знак равенства между ситуацией с выбором между деревом/хеш-таблицей (возникает постоянно например у каждого C++ программиста, т.к. во многих задачах подходит и std::map и std::unordered_map) и ситуацией с необходимостью написания своей реализации дерева/хеш-таблицы (действительно не так уж часто требуется, хотя иногда надо и такое). Т.е. нормальному программисту знание всех этих алгоритмов необходимо не для того, чтобы постоянно писать свои велосипеды (как ты тут пытаешься представить), а для того чтобы выбирать правильную готовую реализацию.

Аналогичная ситуация и с СУБД. Есть множество ситуаций, когда классические СУБД не будут справляться с работой. Но это не означает, что в такой ситуации программист побежит писать свою СУБД — во многих случаях он вполне может выбрать что-то готовое из узкоспециализированных решений. Но чтобы это сделать, он должен хорошо представлять себе процессы внутри.

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

G>·>Ну почитай что-ли Интернет, если слова незнакомые.
G>Слова знакомые. Проблема знакомая. Пиши код так, чтобы минимизировать этот эффект. Например реализуй бизнес логику в хранимых процедурах.
Как, например, из хранимых процедур ты будешь читать, парсить и писать UDP-пакеты?
Блин, в low latency коде бывает проблема GetCurrentTime вызвать с необходимой производительностью, а ты тут про хранимые процедуры...

G>>>Это какой-то разговор в стиле "а вы станьте ежиками". Давай конкретику обсудим. Желательно с кодом.
G>·>Ещё более конкретно, ну например, FX orderbook. Ты правда её в субд запихивать собрался?!!
G>На мосбирже оракл.
А ещё я уверен, что на мосбирже есть .bat-скрипты и 1C. И что?

G>Все прекрасно работает.
А сам ты даже не представляешь как такое делать и какие бывают проблемы.

G>·>Я не понял к чему эта статистика. Да, есть куча формоклёпов, некоторым и страшное слово "хеш-таблица" знать не надо — кинул кнопку на форму и оно как-то работает, считает зарплату 45 минут... А кто-то забивает на СУБД и кнопочки и делает на этом $20M-$50M. И что это по-твоему доказывает?
G>Опять же приведу пример Усманова, который владеет Mail.Ru, а также является самым богатым человеком в России. Он в обще программировать не умеет. Давай у него про СУБД спросим?
У тебя с логикой проблема. Я ни Усманова ни mail.ru в глаза не видел. Какое отношение это всё имеет к дискуссии?

G>>>Ну а как ты организуешь параллельный доступ без мьютексов? Используй табличные переменные тогда. Вариантов масса на самом деле.
G>·>О, боже! Ну например, lock-free algorithms, слыхал?
G>·>В конце концов, от параллельного доступа в коде можно вообще иногда избавиться.
G>А ты слышал про In Memory OLTP. Знаешь как оно работает. Почитай если не знаешь. Применительно к твоей реплике будет полезно. Я серьезно без стеба. Если не знаешь, то надолго запомнишь.
Цифры в студию. Интересует latency histogram.

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

G>Опять же приведу пример Усманова, который владеет Mail.Ru, а также является самым богатым человеком в России.

О, я смотрю у тебя во всех областях одинаково хромающие знания. Усманов вообще то не входит даже в тройку богатейших бизнесменов России (http://www.forbes.ru/rating/342579-200-bogateyshih-biznesmenov-rossii-2017). ))) Похоже, что все цифры, озвученные тобой в данной дискуссиии, ты придумываешь сам, на ходу. )))

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

G>>Опять же приведу пример Усманова, который владеет Mail.Ru, а также является самым богатым человеком в России.
_>О, я смотрю у тебя во всех областях одинаково хромающие знания. Усманов вообще то не входит даже в тройку богатейших бизнесменов России (http://www.forbes.ru/rating/342579-200-bogateyshih-biznesmenov-rossii-2017). ))) Похоже, что все цифры, озвученные тобой в данной дискуссиии, ты придумываешь сам, на ходу. )))
Ради справедливости — он таки недавно был богатейшим. Но в целом да, большинство своих оценок товарищ Gattaka основывает исключительно на своём опыте.

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

·>Как, например, из хранимых процедур ты будешь читать, парсить и писать UDP-пакеты?
·>Блин, в low latency коде бывает проблема GetCurrentTime вызвать с необходимой производительностью, а ты тут про хранимые процедуры...
Вот вы палитесь страшным образом просто. Когда вам говоришь, что не надо втюхивать алгоритмы куда попало. Вы отвечаете: "Кааак?!? Да я же крутой! Я такие космические объемы обрабатываю. Я крутой! Супер программист, а ты никто. Потому что не знаешь бинарные деревья. А я крутой, да как ты смеешь так говорить. Да ты кто такой. Ты понимаешь с каким крутым программистом разговариваешь?" Вот и весь диалог. Ни кода, ни описания систем, ничего. Уверен что кроме вас за ваш код никто больше не возьмется. Там невозможно ничего понять, невозможно поддерживать. Скорее всего там уберешь вызов лишний, а окажется на нем держалась вся low latency проекта!!!! Вот в таком стиле все написано. Тыщу раз уже видел таких крутяков...

G>>>>Это какой-то разговор в стиле "а вы станьте ежиками". Давай конкретику обсудим. Желательно с кодом.
G>>·>Ещё более конкретно, ну например, FX orderbook. Ты правда её в субд запихивать собрался?!!
G>>На мосбирже оракл.
·>А ещё я уверен, что на мосбирже есть .bat-скрипты и 1C. И что?
Нет. Движок биржи — оракл.

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

·>У тебя с логикой проблема. Я ни Усманова ни mail.ru в глаза не видел. Какое отношение это всё имеет к дискуссии?
А я киберакса этого не видел. Неужели аналогия не понятна?

·>Цифры в студию. Интересует latency histogram.
Какие цифры? Lock free хотел — получай. Цифры вон парнишка тут на форбс найдет сейчас

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

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

G>>>Опять же приведу пример Усманова, который владеет Mail.Ru, а также является самым богатым человеком в России.
_>>О, я смотрю у тебя во всех областях одинаково хромающие знания. Усманов вообще то не входит даже в тройку богатейших бизнесменов России (http://www.forbes.ru/rating/342579-200-bogateyshih-biznesmenov-rossii-2017). ))) Похоже, что все цифры, озвученные тобой в данной дискуссиии, ты придумываешь сам, на ходу. )))
·>Ради справедливости — он таки недавно был богатейшим. Но в целом да, большинство своих оценок товарищ Gattaka основывает исключительно на своём опыте.

Все таки забавно, что он сам спалился на подмене фактов

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

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

_>У тебя во всей этой теме наблюдается попытка классической подмены понятий. Ты постоянно пытаешься поставить знак равенства между ситуацией с выбором между деревом/хеш-таблицей (возникает постоянно например у каждого C++ программиста, т.к. во многих задачах подходит и std::map и std::unordered_map) и ситуацией с необходимостью написания своей реализации дерева/хеш-таблицы (действительно не так уж часто требуется, хотя иногда надо и такое). Т.е. нормальному программисту знание всех этих алгоритмов необходимо не для того, чтобы постоянно писать свои велосипеды (как ты тут пытаешься представить), а для того чтобы выбирать правильную готовую реализацию.
Нет это у тебя. Самый начальный топик прочитай. Внимательно. Пожалуйста.

_>Аналогичная ситуация и с СУБД. Есть множество ситуаций, когда классические СУБД не будут справляться с работой. Но это не означает, что в такой ситуации программист побежит писать свою СУБД — во многих случаях он вполне может выбрать что-то готовое из узкоспециализированных решений. Но чтобы это сделать, он должен хорошо представлять себе процессы внутри.
Нет таких ситуаций. Классические СУБД непобедимы.

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

_>>У тебя во всей этой теме наблюдается попытка классической подмены понятий. Ты постоянно пытаешься поставить знак равенства между ситуацией с выбором между деревом/хеш-таблицей (возникает постоянно например у каждого C++ программиста, т.к. во многих задачах подходит и std::map и std::unordered_map) и ситуацией с необходимостью написания своей реализации дерева/хеш-таблицы (действительно не так уж часто требуется, хотя иногда надо и такое). Т.е. нормальному программисту знание всех этих алгоритмов необходимо не для того, чтобы постоянно писать свои велосипеды (как ты тут пытаешься представить), а для того чтобы выбирать правильную готовую реализацию.
G>Нет это у тебя. Самый начальный топик прочитай. Внимательно. Пожалуйста.

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

_>>Аналогичная ситуация и с СУБД. Есть множество ситуаций, когда классические СУБД не будут справляться с работой. Но это не означает, что в такой ситуации программист побежит писать свою СУБД — во многих случаях он вполне может выбрать что-то готовое из узкоспециализированных решений. Но чтобы это сделать, он должен хорошо представлять себе процессы внутри.
G>Нет таких ситуаций. Классические СУБД непобедимы.

Тогда почему гуглопоиск работает не на Oracle? )))

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

G>·>Как, например, из хранимых процедур ты будешь читать, парсить и писать UDP-пакеты?
G>·>Блин, в low latency коде бывает проблема GetCurrentTime вызвать с необходимой производительностью, а ты тут про хранимые процедуры...
G>Вот вы палитесь страшным образом просто. Когда вам говоришь, что не надо втюхивать алгоритмы куда попало. Вы отвечаете: "Кааак?!? Да я же крутой! Я такие космические объемы обрабатываю. Я крутой! Супер программист, а ты никто. Потому что не знаешь бинарные деревья. А я крутой, да как ты смеешь так говорить. Да ты кто такой. Ты понимаешь с каким крутым программистом разговариваешь?" Вот и весь диалог. Ни кода, ни описания систем, ничего. Уверен что кроме вас за ваш код никто больше не возьмется. Там невозможно ничего понять, невозможно поддерживать. Скорее всего там уберешь вызов лишний, а окажется на нем держалась вся low latency проекта!!!! Вот в таком стиле все написано. Тыщу раз уже видел таких крутяков...
Тебе нужно найти другую работу или предметную область, чтобы с такими крутяками поменьше сталкиваться.

G>>>На мосбирже оракл.
G>·>А ещё я уверен, что на мосбирже есть .bat-скрипты и 1C. И что?
G>Нет. Движок биржи — оракл.

Я третий раз спрашиваю — что именно от оракла, где именно и как именно используется?
Вот это — верю: "интеграционного взаимодействия между внутренними системами на промышленное ПО промежуточного слоя – стек продуктов Oracle Fusion Middleware, центральное место в котором занимает Oracle SOA Suite". В то что оракл СУБД стоит где-то в low latency path — не верю. Док-ва в студию, если есть.
Но собственно, я уверен, что ты и нагуглить не способен, вот тебе — рассей своё невежество:

Однако, то дополнительное что мы делаем с этим процессом на Московской бирже, не существует более нигде в мире

ага-ага. Только МосБиржа смогла "осилить оракл".

Ни одна реляционная база данных на стандартном оборудовании не соответствует таким требованиям. Только колоночные СУБД и аппаратные ускорители Exadata, которые мы используем.

Интересно, какие sql-запросы они выполняют на FPGA... "Классические СУБД непобедимы" же. Гы-гы.

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

G>·>У тебя с логикой проблема. Я ни Усманова ни mail.ru в глаза не видел. Какое отношение это всё имеет к дискуссии?
G>А я киберакса этого не видел. Неужели аналогия не понятна?
Я киберакса видел, это, кстати, у него не единственный проданный стартап.
Но аналогия всё равно непонятна. Киберакс — программист и решения, в разработку которых он ведёт — покупают технологически развитые компании за большие деньги.

G>·>Цифры в студию. Интересует latency histogram.
G>Какие цифры? Lock free хотел — получай. Цифры вон парнишка тут на форбс найдет сейчас
Я ничего не хотел в общем-то, я лишь ответил на невежественный вопрос: "Ну а как ты организуешь параллельный доступ без мьютексов?".
Просто ты так авторитетно заявил о In-Memory OLTP, что я понадеялся, что ты про это хоть что-то знаешь и расскажешь какие-то технические подробности о перформансе. Но кроме пресс-релиза ты видимо ничего не видал, настоящий крутяк.

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

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

_>>>Аналогичная ситуация и с СУБД. Есть множество ситуаций, когда классические СУБД не будут справляться с работой. Но это не означает, что в такой ситуации программист побежит писать свою СУБД — во многих случаях он вполне может выбрать что-то готовое из узкоспециализированных решений. Но чтобы это сделать, он должен хорошо представлять себе процессы внутри.
G>>Нет таких ситуаций. Классические СУБД непобедимы.

_>Тогда почему гуглопоиск работает не на Oracle? )))
понты

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

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

·>Какое упёртое тупое невежество.
·>Я третий раз спрашиваю — что именно от оракла, где именно и как именно используется?
·>Вот это — верю: "интеграционного взаимодействия между внутренними системами на промышленное ПО промежуточного слоя – стек продуктов Oracle Fusion Middleware, центральное место в котором занимает Oracle SOA Suite". В то что оракл СУБД стоит где-то в low latency path — не верю. Док-ва в студию, если есть.
·>Но собственно, я уверен, что ты и нагуглить не способен, вот тебе — рассей своё невежество:
·>

Однако, то дополнительное что мы делаем с этим процессом на Московской бирже, не существует более нигде в мире

·>ага-ага. Только МосБиржа смогла "осилить оракл".
·>

Ни одна реляционная база данных на стандартном оборудовании не соответствует таким требованиям. Только колоночные СУБД и аппаратные ускорители Exadata, которые мы используем.

·>Интересно, какие sql-запросы они выполняют на FPGA... "Классические СУБД непобедимы" же. Гы-гы.
По пресс релизам судит Ну да журналистам виднее

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

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

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

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


_>>Тогда почему гуглопоиск работает не на Oracle? )))
G>понты

Берите круче: за яву обиделись и решили написать свое А так они конечно бы сидели на оракле. Или mssql.

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

S>Берите круче: за яву обиделись и решили написать свое А так они конечно бы сидели на оракле. Или mssql.
Мне смешно от этих вопросов на самом деле. А вот гугл используют такую то хреновину. И что? Какое отношение гугл имеет к тому чем вы занимаетесь? Это другая лига, считайте что они там не программированием занимается. Количество перешло в качество настолько, что уже можно не смотреть что делает гугл. Гораздо интереснее какая-нибудь контора типа ФБ Софт.

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

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

S>>Берите круче: за яву обиделись и решили написать свое А так они конечно бы сидели на оракле. Или mssql.
G>Мне смешно от этих вопросов на самом деле. А вот гугл используют такую то хреновину. И что? Какое отношение гугл имеет к тому чем вы занимаетесь? Это другая лига, считайте что они там не программированием занимается. Количество перешло в качество настолько, что уже можно не смотреть что делает гугл. Гораздо интереснее какая-нибудь контора типа ФБ Софт.

Это пример того, как людям не достаточно СУБД. Им приходится использовать и изобретать в большом кол-ве алгоритмы и различные структуры данных, чтобы решить свою задачу.