Сама архитектура его приложения показывает, что он принимал запросы по http. Иначе зачем ему менеджер http-запросов, который перенаправляет запросы к пулу тредов, где запущены БД?
Современные — это значит существующие в настоящее время и активно развивающиеся.
Вы влезли в дискуссию, не заметив фразу smagen
Когда переписывали на Си или ассемблере с интерпретируемого языка – да.
…
Поэтому я не понимаю, какое отношение это имеет к дискуссии.
А отношение такое, что многие современные БД написаны на интерпретируемых языках. При чём если язык, компилируется в байт-код, то он всё равно интерпретируемый (википедия). Таких баз много. Я сразу привёл наиболее яркий пример — CouchDB. Баз на Java огромное количество.
То что smagen не понял как это относится к дискуссии означает, что он этого не знал.
Современная БД — существующая в настоящее время и активно развивающаяся.
С того, что запросы подавались по http.
Приложение делающее запросы + Менеджер http-запросов + несколько тредов [Node.js + GlobalsDB].
Только то, что в квадратных скобках было в одном процессе.
Дело в том, что дерево глобала, которое я рисую оно не совпадает с внутренним B-tree. Логически из одного узла может выходить 1000 ветвей, но внутри только 2 и гораздо больше уровней.
Если считать дерево на рисунках отображающем реальную логику работы глобала, то получается, что мы будем искать одну ветвь из 1000 перебором, что неверно.
Я думаю, что если бы изначально я написал, что данные в глобале проиндексированы (т.е. обеспечивают быстрый доступ) по всем ветвям, то это бы вас устроило.
Вас смутила фраза про индексированное хранилище. У глобалов я должен вручную строить индексы, а в реляционных БД это происходит автоматически.
Небольшая разница в смысле, которая накладывает на разработчика систем на глобалах несколько больше работы.
Требование бесспорности — это максимализм и субъективизм, есть люди которые всегда спорят. Я лично считаю, что наиболее ценна спорная информация, так как она может дать фору (пока остальные тормозят) и привести к взрывному прогрессу.
Прекрасно. Поскольку я не разработчик баз на глобалах, то я ответил в меру своего понимания о том, что помогло получить такие результаты.
Для кого-то это уже полезная информация. Поскольку я хотя бы бегло уже смотрел исходный код и потратил приличное время на изучение экокультуры глобалов.
Доказательство каждого конкретного пункта из этого списка не входит в мои планы.
Это то, как я сам для себя объясняю полученные результаты.
Информация о существовании протестированной технологии с высоким потенциалом — уже ценная вещь.
Про них уже написали. При современных процессорах и компиляторах, они далеко не всегда уместны. Особенно те, которые появились в результате долгого развития.
То что у кого-то ассемблерные оптимизации не работают и долгое развитие не развивает — это не доказательство того, что в глобалах это бесполезно.
Вы действительно считаете все эти аналогии уместными? Может быть я говорю с апостолом от InterSystems?
Аналогия абсолютна уместна, так как вы не желаете проводить собственные эксперименты и не признаёте ссылки на проведённые. Для вас критерий истинности — это не практика, а чтобы вам теоретически нечто доказали. Что может быть принципиально невозможным, так как явно у вас есть какой-то негатив, связанный с этой технологией.
И в конце статьи жирным шрифтом есть Disclaimer. Почитайте и узнаете являюсь ли я «апостолом».
Но если вы объясняете ими разницу на порядок – это вызывает совершенно законные вопросы.
На Хабре полно статей, когда программу переписывали на Си или ассемблере и получали выигрыш на несколько порядков.. Читайте, просвещайтесь.
Это очень удобная позиция — не принимать чужие аргументы. Вот вы не принимаете аргумент долгого развития, а я в качестве примера приведу вам, что php 1.0 в десятки тысяч раз медленнее современной реализации. Php 4.0 медленнее php 5.0 в разы. А базы на глобалах это, образно говоря, технология 90.0.
Докажите мне, что долгое развитие ничего не даёт, а потом говорите это этот аргумент ничтожен.
Тот факт, что вы не засчитали мой аргумент об ассемблере, сославшись на коммент, где говорится что иногда компиляторы создают машинный код не хуже человека.
Фома Неверующий — наименее верующий из всех апостолов. По легендам он лично проверял раны Христа, не поверив другим.
Если продолжать аналогию с Фомой, то если бы вы были на месте Фомы, то сказали бы: нет, Иисус, руки в раны вкладывать не стану. Я поверю только тогда, когда ты мне объяснишь Теорию воскресения, сотворения мира и Триединства)))
Вот вы можете мне доказать, что ассемблерные ручные оптимизации ВСЕГДА хуже по быстродействию, чем код который создают компиляторы? Нет?
Тогда факт, что более 50% кода написано на ассемблере достаточен.
А доказать, что долгая работа над кодом ВСЕГДА не приводит к улучшению продукта? Тоже нет?
Значит объяснение я вам предоставил.
Ваша аргументы откровенно слабы: в каких-то случаях компилятор так же хорош как человек, в каких-то случаях долгое развитие фигня. Где-то иногда можно не использовать интерпретатор SQL, а написать много хранимок, которые в некоторых БД окажутся хорошо откомпилированными, а не тупо сохранёнными как текст.
Для того, чтобы быть уверенным, что кирпич падает с такой же скоростью как гиря, необязательно знать квантовую механику и теорию гравитации. Достаточно провести тесты.
Нужно более глубокое и детализированное знание — спросите у разработчиков. Или почитайте исходные коды. Благо они есть. Напишите статью с выводами. Все вам будут благодарны.
Я предлагаю вам повторить самостоятельно какие-то из моих или тестов Роба Твида, поскольку только так вы можете сами убедиться.
Очевидно, что вы like Фома Неверующий, который может с чем-то согласиться только проведя самостоятельные тесты. Поэтому спор бесполезен. Буду рад почитать вашу статью с результатами тестирования.
Напишите хранимку для инсерта случайных данных на SQL и на COS/M. И сравните скорость. Я делал сравнение с MySQL и для хранимок, и для интерпретаторного режима. В обоих случая глобалы были быстрее, как минимум, на порядок. Вот результаты одного из моих тестов. В нём я тестировал интерпретаторный режим GT.M (без компиляции) и MySql (без хранимок).
Теоретически компилятор может написать код лучше человека, а долгая работа над кодом талантливых программистов не приводить к его улучшению, а в программах можно использовать только хранимые процедуры, отказавшись от SQL. Но на практике это бывает редко.
Когда база помещается в буфера — это только когда делается сравнительное тестирование с in-memory БД, которые не могут работать с базами большего объёма.
Я многократно использовал в тестах 100-300M вставок, которые НЕ помещаются ни в какие буфера и винты хрустят как бешеные. И при этом получал всё равно сотни тысяч инсертов в секунду.
Хорошо. Вы фокусируете меня на том, что индекс — это более общее понятие, чем первичный ключ.
Я согласен.
Индекс работает O(log(N)) и дерево работает O(log(N)). Потому что индексы внутри тоже деревья. Отличие семантическое очень тонкое.
Если при первоначальной вставке я подобрал правильную структуру дерева и сразу делаю несколько вспомогательных деревьев, то, фактически, материальная база для нужных мне быстрых поисков по нужным полям также будет создана.
По смыслу это эквивалентно, что заполнил таблицу с основным и вторичными ключами с разницей в том, что мне нужно будет самому писать процедуры для правильного осуществления этого поиска (если я не использую SQL-доступ).
А ведь я могу заполнить все нужные деревья, а потом обращаться к ним вообще из SQL. И интерпретатор SQL в Caché автоматически будет использовать мои вспомогательные деревья и использовать их как вторичные индексы.
Вопрос: чем это отличается от индексированного хранилища?
Я вижу лишь отличие на уровне глобалов — там мне действительно придётся писать доп. процедуры для выборок с использованием вторичных индексов и там нет той высокоуровневой работы с индексами, свойственной SQL.
^a(«city») — это не таблица.
Чтобы вам было проще используйте аналогию, что глобал — это таблица — ^a.
В глобалах семантика своя. Я пытаюсь найти аналогии для людей из известных терминов.
И, как следствие, результаты получаются различными.
Какие именно результаты различны?
Когда я запрашиваю ветви узла (команда $Order) ^a(5, «city») это эквивалентно тому что я делаю:
Select city from a where id=5 Order by city
(Допустим в таблице содержатся маршруты коммивояжера)
Если мне нужно только значение ^a(5, «city») это эквивалентно
Select city from a where id=5
(Таблица с личными данными)
Алгоритмическая сложность — точно не знаю. Учитывая, что всё построено на разновидностях B-tree примерно O(log(N)).
На практике при вставке 300M значений я не замечал никакого торможения, кроме как из-за забивающегося кеша на запись. Когда европейское космическое агентство тестировало вставку на протяжении нескольких дней, то тоже не заметили торможения вызванного разбуханием глобала.
Вы влезли в дискуссию, не заметив фразу smagen
А отношение такое, что многие современные БД написаны на интерпретируемых языках. При чём если язык, компилируется в байт-код, то он всё равно интерпретируемый (википедия). Таких баз много. Я сразу привёл наиболее яркий пример — CouchDB. Баз на Java огромное количество.
То что smagen не понял как это относится к дискуссии означает, что он этого не знал.
Современная БД — существующая в настоящее время и активно развивающаяся.
Приложение делающее запросы + Менеджер http-запросов + несколько тредов [Node.js + GlobalsDB].
Только то, что в квадратных скобках было в одном процессе.
Если считать дерево на рисунках отображающем реальную логику работы глобала, то получается, что мы будем искать одну ветвь из 1000 перебором, что неверно.
Ваше мнение: как следовало сказать правильно?
Вас смутила фраза про индексированное хранилище. У глобалов я должен вручную строить индексы, а в реляционных БД это происходит автоматически.
Небольшая разница в смысле, которая накладывает на разработчика систем на глобалах несколько больше работы.
Я всё правильно понял?
Такое что современные БД почти не пишут на Си. В лучшем случае C++, а в некоторых вообще Erlang (CouchDB например).
А раз вы этого не знаете, то я делаю вывод, что слабые знания современных СУБД именно у вас.
Итак, вы утверждаете, что невозможно получить выигрыш на порядок переписав программу с C++ на ассемблере?
Это то, что можно сказать 10 словами вместо 100 000 строк release notes за последние 40 лет.
Поиск по слову «TSTART» на странице.
Насчёт индексов и сортировок я выкладывал ссылки на внутреннее устройство баз, на детали технической реализации.
Какие факты вам нужны насчёт индексов и сортировок?
Требование бесспорности — это максимализм и субъективизм, есть люди которые всегда спорят. Я лично считаю, что наиболее ценна спорная информация, так как она может дать фору (пока остальные тормозят) и привести к взрывному прогрессу.
Факты я предоставил. Конкретные и с цифрами.
С вашей фразой согласен.
Для кого-то это уже полезная информация. Поскольку я хотя бы бегло уже смотрел исходный код и потратил приличное время на изучение экокультуры глобалов.
Доказательство каждого конкретного пункта из этого списка не входит в мои планы.
Это то, как я сам для себя объясняю полученные результаты.
Информация о существовании протестированной технологии с высоким потенциалом — уже ценная вещь.
То что у кого-то ассемблерные оптимизации не работают и долгое развитие не развивает — это не доказательство того, что в глобалах это бесполезно.
Вы принимаете факт быстроты глобалов? Да или нет.
Аналогия абсолютна уместна, так как вы не желаете проводить собственные эксперименты и не признаёте ссылки на проведённые. Для вас критерий истинности — это не практика, а чтобы вам теоретически нечто доказали. Что может быть принципиально невозможным, так как явно у вас есть какой-то негатив, связанный с этой технологией.
И в конце статьи жирным шрифтом есть Disclaimer. Почитайте и узнаете являюсь ли я «апостолом».
На Хабре полно статей, когда программу переписывали на Си или ассемблере и получали выигрыш на несколько порядков.. Читайте, просвещайтесь.
Это очень удобная позиция — не принимать чужие аргументы. Вот вы не принимаете аргумент долгого развития, а я в качестве примера приведу вам, что php 1.0 в десятки тысяч раз медленнее современной реализации. Php 4.0 медленнее php 5.0 в разы. А базы на глобалах это, образно говоря, технология 90.0.
Докажите мне, что долгое развитие ничего не даёт, а потом говорите это этот аргумент ничтожен.
А раз вы его не приняли, тогда докажите мне, что ассемблерные оптимизации вовсе не дают никогда выигрышей.
Если продолжать аналогию с Фомой, то если бы вы были на месте Фомы, то сказали бы: нет, Иисус, руки в раны вкладывать не стану. Я поверю только тогда, когда ты мне объяснишь Теорию воскресения, сотворения мира и Триединства)))
Вот вы можете мне доказать, что ассемблерные ручные оптимизации ВСЕГДА хуже по быстродействию, чем код который создают компиляторы? Нет?
Тогда факт, что более 50% кода написано на ассемблере достаточен.
А доказать, что долгая работа над кодом ВСЕГДА не приводит к улучшению продукта? Тоже нет?
Значит объяснение я вам предоставил.
Ваша аргументы откровенно слабы: в каких-то случаях компилятор так же хорош как человек, в каких-то случаях долгое развитие фигня. Где-то иногда можно не использовать интерпретатор SQL, а написать много хранимок, которые в некоторых БД окажутся хорошо откомпилированными, а не тупо сохранёнными как текст.
Для того, чтобы быть уверенным, что кирпич падает с такой же скоростью как гиря, необязательно знать квантовую механику и теорию гравитации. Достаточно провести тесты.
Нужно более глубокое и детализированное знание — спросите у разработчиков. Или почитайте исходные коды. Благо они есть. Напишите статью с выводами. Все вам будут благодарны.
Очевидно, что вы like Фома Неверующий, который может с чем-то согласиться только проведя самостоятельные тесты. Поэтому спор бесполезен. Буду рад почитать вашу статью с результатами тестирования.
Напишите хранимку для инсерта случайных данных на SQL и на COS/M. И сравните скорость. Я делал сравнение с MySQL и для хранимок, и для интерпретаторного режима. В обоих случая глобалы были быстрее, как минимум, на порядок. Вот результаты одного из моих тестов. В нём я тестировал интерпретаторный режим GT.M (без компиляции) и MySql (без хранимок).
Теоретически компилятор может написать код лучше человека, а долгая работа над кодом талантливых программистов не приводить к его улучшению, а в программах можно использовать только хранимые процедуры, отказавшись от SQL. Но на практике это бывает редко.
Когда база помещается в буфера — это только когда делается сравнительное тестирование с in-memory БД, которые не могут работать с базами большего объёма.
Я многократно использовал в тестах 100-300M вставок, которые НЕ помещаются ни в какие буфера и винты хрустят как бешеные. И при этом получал всё равно сотни тысяч инсертов в секунду.
Я согласен.
Индекс работает O(log(N)) и дерево работает O(log(N)). Потому что индексы внутри тоже деревья. Отличие семантическое очень тонкое.
Если при первоначальной вставке я подобрал правильную структуру дерева и сразу делаю несколько вспомогательных деревьев, то, фактически, материальная база для нужных мне быстрых поисков по нужным полям также будет создана.
По смыслу это эквивалентно, что заполнил таблицу с основным и вторичными ключами с разницей в том, что мне нужно будет самому писать процедуры для правильного осуществления этого поиска (если я не использую SQL-доступ).
А ведь я могу заполнить все нужные деревья, а потом обращаться к ним вообще из SQL. И интерпретатор SQL в Caché автоматически будет использовать мои вспомогательные деревья и использовать их как вторичные индексы.
Вопрос: чем это отличается от индексированного хранилища?
Я вижу лишь отличие на уровне глобалов — там мне действительно придётся писать доп. процедуры для выборок с использованием вторичных индексов и там нет той высокоуровневой работы с индексами, свойственной SQL.
Чтобы вам было проще используйте аналогию, что глобал — это таблица — ^a.
В глобалах семантика своя. Я пытаюсь найти аналогии для людей из известных терминов.
Какие именно результаты различны?
Когда я запрашиваю ветви узла (команда $Order) ^a(5, «city») это эквивалентно тому что я делаю:
Select city from a where id=5 Order by city
(Допустим в таблице содержатся маршруты коммивояжера)
Если мне нужно только значение ^a(5, «city») это эквивалентно
Select city from a where id=5
(Таблица с личными данными)
Алгоритмическая сложность — точно не знаю. Учитывая, что всё построено на разновидностях B-tree примерно O(log(N)).
На практике при вставке 300M значений я не замечал никакого торможения, кроме как из-за забивающегося кеша на запись. Когда европейское космическое агентство тестировало вставку на протяжении нескольких дней, то тоже не заметили торможения вызванного разбуханием глобала.