Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Мне кажется, что автор данного топика не совсем понимает, о чем ведет речь.
К сожалению, нынче модные интерпретируемые и полуинтерпретируемые языки программирования, такие как C#, 1C, Java, не имеют средств, для прямой работы с памятью, поэтому в нынешнем виде они непригодны для разработки в будущем.
Вообще-то всякие маленькие базы данных типа SqlCE работают in-process с приложением — не важно на чем оно написано. Тут скорее не язык должен это поддерживать, а сама база данных.
Ну и справедливости ради: c# и java уже давно не интерпретируемые, потому и достаточно шустрые. А процедуры на них (соответственно в mssql и oracle/postgres) работают с объектом соединения фактически на разделяемой памяти, что опять же не может положительно сказываться на производительности. Ну и массированную запись опять таки можно распараллелить по какому-либо показателю между серверами приложений. Точно так же с выборкой. — таблицы кластеризуются например по годам. Проверено как раз на АБСке одного крупного производителя в ритейле
Поэтому я их назвал «полуинтерпретируемыми»
| Проверено как раз на АБСке одного крупного производителя в ритейле
Извиняюсь, за возможно некорректный вопрос… Хотелось бы оценить объём данных, с которыми приходится работать ритейлу. Т.е. интересно, на сколько гигабайт растёт база в год и на сколько гигабайт растёт размер сжатого архива этой базы (для оценки фактического объёма данных в базе)
Извиняюсь, за возможно некорректный вопрос… Хотелось бы оценить объём данных, с которыми приходится работать ритейлу. Т.е. интересно, на сколько гигабайт растёт база в год и на сколько гигабайт растёт размер сжатого архива этой базы (для оценки фактического объёма данных в базе)
Какая-то каша.
Хотя если считать основной мысль о том, что неплохо бы ОРМ совершить некоторый эволюционный скачок, то я соглашусь.
Совсем не раскрыта роль кэшей, а без них в тяжелых приложениях никак. Ну и NoSQL решения уже давно шагают по планете, на них хотя бы можно переложить сбор внутренней статистики и протоколирование некритичных операций.
Разговаривать про некие «общесистемные» пороги ограничений бессмысленно, пока речь не идет о конкретной архитектуре, конкретной БД с ее скоростью индексов, и конкретных ресурсах. Какие-то ограничения относительно БД всегда будут и проблема их существования решается архитектурно, путем балансированием в пределах CAP в соответствии с задачами.
Хотя если считать основной мысль о том, что неплохо бы ОРМ совершить некоторый эволюционный скачок, то я соглашусь.
Совсем не раскрыта роль кэшей, а без них в тяжелых приложениях никак. Ну и NoSQL решения уже давно шагают по планете, на них хотя бы можно переложить сбор внутренней статистики и протоколирование некритичных операций.
Разговаривать про некие «общесистемные» пороги ограничений бессмысленно, пока речь не идет о конкретной архитектуре, конкретной БД с ее скоростью индексов, и конкретных ресурсах. Какие-то ограничения относительно БД всегда будут и проблема их существования решается архитектурно, путем балансированием в пределах CAP в соответствии с задачами.
Интересуют тесты в результате которых получены цифры и конфигурация железо\СУБД
Статья в которой читатель узнаёт, что 1С это нынче модный язык программирования, но у него как и Java с 1С нет никаких шансов в будущем.
Разумеется, красивых цифр не бывает. Разумеется, на разных системах были разные данные. Напрмер, в статье приведены данные, о том, что Oracle строит индекс по 1 млн элементов за 20 секунд, т.е. 50 000 строк в секунду. Тем не менее, я оцениваю этот показатель в 100 000 строк в секунду. Естесственно, при таком округлении не имеет значение, было ли там 20 секунд или 22 секунду. На смысл статьи это не влияет. FireBird строит индексы, например, со скоростью 20 000 строк в секунду. И это самый большой недостаток этой базы данных, с которой мне пришлось несколько лет работать. Процессор Pentium III 1000 МГц 1 Гб ОЗУ строит индекс по 100 млн элементов за 0,54 — это данные, которые я получил сам в далёком 2003-м году.
Надо сказать, что я оценивал качество своих тестов, сравнивая достигнутые результаты с результатами у других людей. И у других цифры были гораздо ниже.
Надо сказать, что я оценивал качество своих тестов, сравнивая достигнутые результаты с результатами у других людей. И у других цифры были гораздо ниже.
>«Oracle строит индекс по 1 млн элементов за 20 секунд, т.е. 50 000 строк в секунду. Тем не менее, я оцениваю этот показатель в 100 000 строк в секунду» — я чего-то догоняю
Ну вы сравните 100 тысяч и 100 миллионов — разница в три порядка. И округление в 50 000 на фоне такой разницы (кстати, в пользу баз данных) не имеет большого значения.
Oracle строит индекс по 1 млн элементов за 20 секунд
Вы же понимаете, что это ооооочень сильно зависит от железа и нагрузки.
Вот мой тестовый сервак, здесь железо далеко не продуктивное:
SQL> set timing on
SQL> create table test as select level val from dual connect by level <= 1e6;
Table created
Executed in 1.312 seconds
SQL> create index test$val$idx on test(val);
Index created
Executed in 0.75 secondsИ нельзя, нельзя сравнивать построение индекса и скорость сортировки. Индекс это построение сбалансированного двоичного дерева, цель которого — увеличение скорости доступа к данным. Это куда больше чем просто получение отсортированного набора данных. Если вы попытаетесь самостоятельно построить двоичное дерево, пусть и без сброса на диск, лишь в оперативе, я полагаю вам придется изрядно потрудиться, чтобы таки померяться с ораклом.
>Особенность применения ООП в том, что оно порождает кучу мелких >обращений к базе данных.
Кучу мелких запросов в БД делает неопытный программист, и не важно какой подход к разработке применяется.
Кучу мелких запросов в БД делает неопытный программист, и не важно какой подход к разработке применяется.
ООП поощряет неопытного программиста к созданию кучи мелких запросов, а у опытных не всегда есть время, чтобы помогать исправлять такие вещи
При чем здесь ООП вообще? Каким образом оно что-либо поощряет? В конструкторе объектов по дефолту зашито обращение к БД?
ООП и БД — это абсолютно разные, непересекающиеся, друг от друга независимые вещи.
При прочтении статьи у меня сложилось впечатление, что ваша профессия — системный аналитик, консультант или что-либо наподобие, потому что (моё мнение) вы никогда не писали код. Вы не являетесь специалистом по Java, C#, теории языков программирования, вы не знаете, что такое JIT компиляция и т.д.
Что это за цифра? Откуда она взялась, какие конкретно запросы вы имели ввиду, какая СУБД, какое железо, какой совокупный объем данных, какие индексы БД?
В общем для того, чтоб делать ТАКИЕ громкие заявления, в статье не хватает аргументов.
ООП и БД — это абсолютно разные, непересекающиеся, друг от друга независимые вещи.
При прочтении статьи у меня сложилось впечатление, что ваша профессия — системный аналитик, консультант или что-либо наподобие, потому что (моё мнение) вы никогда не писали код. Вы не являетесь специалистом по Java, C#, теории языков программирования, вы не знаете, что такое JIT компиляция и т.д.
8000 SQL-запросов за секунду
Что это за цифра? Откуда она взялась, какие конкретно запросы вы имели ввиду, какая СУБД, какое железо, какой совокупный объем данных, какие индексы БД?
В общем для того, чтоб делать ТАКИЕ громкие заявления, в статье не хватает аргументов.
1) При чём здесь ООП
ООП, за 30 лет своего существования, подтвердило свою эффективность. Поэтому всегда стараются писать в объектном стиле, даже если программируют для реляционных баз данных.
2) Каким образом ООП поощряет к созданию кучи мелких запросов
Вы правильно отметили, что ООП и БД это разные вещи и они сложно друг с другом сочетаются. Давайте рассмотрим случай, когда есть два класса: «книга» и «автор». У автора есть поле «Имя». У книги есть «Название» и ссылка на автора. Предполагается, что если вы пишете на объектно-ориентированном языке, то вывод списка книг с именами авторов будет выглядеть примерно следующим образом
примерно так пишут в учебниках. Теперь, если мы используем объектную надстройку над реляционной базой данных, то мы также можем получить список книг ввиде массива. Но в этом массиве не будет имени автора, а для того чтобы его получить, такая программа будет на каждой итерации цикла порождать SQL запрос к базе для получения имени одного единственного автора.
Вот таким образом ООП и поощряет новичков на порождение кучи мелких запросов.
3) Про 8000 строк — подобный вопрос уже был, я на него ответил ниже. Это число было получено в результате очень сильной оптимизации алгоритмов репликации данных между серверами
4) Про «ТАКИЕ громкие заявления»
Выводы напрямую следуют из цифр, полученных в результате тестов. Для того чтобы сделать другой вывод нужно либо найти ошибку в цепочке логиечских рассуждений, либо показать, что цифры неверны.
ООП, за 30 лет своего существования, подтвердило свою эффективность. Поэтому всегда стараются писать в объектном стиле, даже если программируют для реляционных баз данных.
2) Каким образом ООП поощряет к созданию кучи мелких запросов
Вы правильно отметили, что ООП и БД это разные вещи и они сложно друг с другом сочетаются. Давайте рассмотрим случай, когда есть два класса: «книга» и «автор». У автора есть поле «Имя». У книги есть «Название» и ссылка на автора. Предполагается, что если вы пишете на объектно-ориентированном языке, то вывод списка книг с именами авторов будет выглядеть примерно следующим образом
for (int i=0; i<books_count; i++)
{
print ("%s %s", book[i].name, books[i].autor.name);
}
примерно так пишут в учебниках. Теперь, если мы используем объектную надстройку над реляционной базой данных, то мы также можем получить список книг ввиде массива. Но в этом массиве не будет имени автора, а для того чтобы его получить, такая программа будет на каждой итерации цикла порождать SQL запрос к базе для получения имени одного единственного автора.
Вот таким образом ООП и поощряет новичков на порождение кучи мелких запросов.
3) Про 8000 строк — подобный вопрос уже был, я на него ответил ниже. Это число было получено в результате очень сильной оптимизации алгоритмов репликации данных между серверами
4) Про «ТАКИЕ громкие заявления»
Выводы напрямую следуют из цифр, полученных в результате тестов. Для того чтобы сделать другой вывод нужно либо найти ошибку в цепочке логиечских рассуждений, либо показать, что цифры неверны.
При чем здесь ООП вообще?
ООП это прежде всего подход. Подход, при котором еденица воздействия — объект. Если мы попытаемся применить этот подход к обработке больших массивов данных, мы будем вынуждены работать не с множествами объектов, а с каждым объектом по отдельности.
ООП и БД — это абсолютно разные, непересекающиеся, друг от друга независимые вещи.
Абсолютно верно. Но в последнее время действительно имеется тенденция применения объектной парадигмы при работе и с реляционными данными. Многие фреймворки маскируют реляционный слой, предоставляя его ОО обертку. 1С — прекрасный тому пример.
> поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.
Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?
> даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду
> сетевом взаимодействии задействовано ещё больше процессов, соответственно и число запросов уменьшается практически до 1000.
Очень интересно узнать: как измеряли/считали?
Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?
> даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду
> сетевом взаимодействии задействовано ещё больше процессов, соответственно и число запросов уменьшается практически до 1000.
Очень интересно узнать: как измеряли/считали?
>> поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.
> Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?
здесь видимо претензия к тому что, я включил в список на распараллеливание сервер приложений. Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.
>Очень интересно узнать: как измеряли/считали
Данные получены в результате работы над системами репликации данных между серверами баз данных. Достоверность данных проверялась, путём сопоставления с даннымми из других источников.
Например только сегодня появилась статья:
habrahabr.ru/post/139708/
В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а. Так что достоверность данных из статьи в очередной раз подтвердилась.
Тем не менее кто-нибуть предоставит более высокие данные — буду рад посмотреть, как ему удалось их получить.
> Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?
здесь видимо претензия к тому что, я включил в список на распараллеливание сервер приложений. Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.
>Очень интересно узнать: как измеряли/считали
Данные получены в результате работы над системами репликации данных между серверами баз данных. Достоверность данных проверялась, путём сопоставления с даннымми из других источников.
Например только сегодня появилась статья:
habrahabr.ru/post/139708/
В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а. Так что достоверность данных из статьи в очередной раз подтвердилась.
Тем не менее кто-нибуть предоставит более высокие данные — буду рад посмотреть, как ему удалось их получить.
Скорость работы корпоративных приложений вообще не зависит ни от языка, ни от компилятора, ни от базы данных. У них сложность высокая, описанные в статье факты не занимают и десятка процентов от общей сложности.
На этом же сайте есть блог ЕРП, он как раз про корпоративные приложения. Статей непосредственно по коду или скриптам там практически нет, именно по вышеописанной причине.
На этом же сайте есть блог ЕРП, он как раз про корпоративные приложения. Статей непосредственно по коду или скриптам там практически нет, именно по вышеописанной причине.
Да, верно, скорость работы корпоративных приложений практически не зависит ни от языка программирования, ни от базы данных. Узким местом, как это и показано в статье, является связь между «языком программирования» и базой данных. И чтобы это узкое место убрать, нужно либо логику разместить внутри базы данных, либо базу данных разместить внутри сервера приложений. Оба этих метода в статье рассмотрены.
раз ни база ни язык программирования не являются узким местом то и не важно что там между ними происходит.
Статья из раздела «Я сам даже маленькую бухгалтерию не написал но сейчас буду рассказывать как это делать правильно».
Статья из раздела «Я сам даже маленькую бухгалтерию не написал но сейчас буду рассказывать как это делать правильно».
Тесты показывают, что вы ошибаетесь, и накладные расходы на взаимодействие очень велики.
нет тут никаких тестов. Повторюсь:
Статья из раздела «Я сам даже маленькую бухгалтерию не написал но сейчас буду рассказывать как это делать правильно»
Статья из раздела «Я сам даже маленькую бухгалтерию не написал но сейчас буду рассказывать как это делать правильно»
Вы не доверяете каким-то цифрам? — давайте перепроверим…
Что перепроверять-то? Вот утверждение из текста:
да легко SQL-сервер может выполнять 8000 SQL-запросов в секунду. На хабре полно людей которые с такой нагрузкой работают. Вот и всё.
Для справки
— результат запроса может кешироваться SQL-сервером
— отдельные части результатов запроса могут кешироваться и объединяться
— данные могут кешироваться в памяти
— план запроса SQL-сервером строится как в зависимости от данных так и в зависимости от нагрузки
И это при том что само использование термина запрос в таком контексте некорректно т.к. запросы могут выполняться мгновенно а могут расчитываться в течении пары суток.
Значит, даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду.да легко SQL-сервер может выполнять 8000 SQL-запросов в секунду. На хабре полно людей которые с такой нагрузкой работают. Вот и всё.
Для справки
— результат запроса может кешироваться SQL-сервером
— отдельные части результатов запроса могут кешироваться и объединяться
— данные могут кешироваться в памяти
— план запроса SQL-сервером строится как в зависимости от данных так и в зависимости от нагрузки
И это при том что само использование термина запрос в таком контексте некорректно т.к. запросы могут выполняться мгновенно а могут расчитываться в течении пары суток.
Вы можете себе представить, чтоб ваш SQL-сервер выполнял 100 млн запросов в секунду? Нет? — вот об этом и идёт речь. Никто не спорит, и в статье об этом говорится, что в результате различных оптимизаций SQL-сервер можно разогнать до 100 тысяч запросов в секунду. Но 100 миллионов ему не по зубам.
При желании можно и один запрос написать который завалит сервер.
Дурное дело нехитрое.
Дурное дело нехитрое.
Или вызовет segfault: bugs.mysql.com/bug.php?id=60279 ;)
Так можно целую серию статей написать %) «Почему нельзя читать со скоростью 100 млн знаков/с», «Почему коты не бегают со скоростью 100 млн км/ч»…
«Можно повысить общую скорость путём кластеризации» это и есть те самые различные очень тонкие способы оптимизации?
«Можно повысить общую скорость путём кластеризации» это и есть те самые различные очень тонкие способы оптимизации?
Посмотрел ваш профиль…
Не подскажете, можно ли в Java каким-либо образом организовать маппирование файла в память. Например, через native-интерфейс вызвать системную функцию по маппингу файла и потом каким-либо образом работать с выделенным участком адрессного пространства как с обычным Java-массивом.
Не подскажете, можно ли в Java каким-либо образом организовать маппирование файла в память. Например, через native-интерфейс вызвать системную функцию по маппингу файла и потом каким-либо образом работать с выделенным участком адрессного пространства как с обычным Java-массивом.
Не знаю Java, но я бы начал с этого: stackoverflow.com/questions/1125534/what-is-the-best-way-to-access-memory-in-java-similar-to-mmap
С вашим выводом я, в общем и целом, согласен, как и с некоторыми тезисами.
Применение парадигмы ООП действительно существенно увеличивает показатель запросов/секунду. Закрытие периода выполненное в традициях этого подхода, действительно заспамит базу данных запросами. В то же время можно и обойтись десятком — другим запросов, но это уже больше ближе к выносу логики на сторону сервера.
Однако подводка… действительно заставляет недоумевать.
Разумное зерно в вашей статье безусловно есть. Но оно далеко не на поверхности. И от него очень отвлекают спорно сформулированные тезисы и сферические цифры в вакууме.
Думаю, люди вас просто не поняли — очень подкачало изложение.
Применение парадигмы ООП действительно существенно увеличивает показатель запросов/секунду. Закрытие периода выполненное в традициях этого подхода, действительно заспамит базу данных запросами. В то же время можно и обойтись десятком — другим запросов, но это уже больше ближе к выносу логики на сторону сервера.
Однако подводка… действительно заставляет недоумевать.
Разумное зерно в вашей статье безусловно есть. Но оно далеко не на поверхности. И от него очень отвлекают спорно сформулированные тезисы и сферические цифры в вакууме.
Думаю, люди вас просто не поняли — очень подкачало изложение.
> Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.
Независимые друг от друга запросы мало кому нужны, обычно хочется чтобы после обновления баланса одной тётенькой-бухгалтером его и остальные увидели обновлённым. Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД. Соответственно они и всплывают все и сразу на этом уровне.
> В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а.
Автор занимался не тестированием РДБ, тем более что выборка ведётся из служебной таблицы содержимое которой даже ен приведено в статье, а запись даже не рассматривалась. Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Взгляните ещё раз внимательно проблему которую пытаетесь рассмотреть в статье — она состоит из нескольких очень ортогональных частей. Вы пытаетесь свалить всё в кучу и решить оптом, это очень-очень сложно.
Независимые друг от друга запросы мало кому нужны, обычно хочется чтобы после обновления баланса одной тётенькой-бухгалтером его и остальные увидели обновлённым. Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД. Соответственно они и всплывают все и сразу на этом уровне.
> В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а.
Автор занимался не тестированием РДБ, тем более что выборка ведётся из служебной таблицы содержимое которой даже ен приведено в статье, а запись даже не рассматривалась. Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Взгляните ещё раз внимательно проблему которую пытаетесь рассмотреть в статье — она состоит из нескольких очень ортогональных частей. Вы пытаетесь свалить всё в кучу и решить оптом, это очень-очень сложно.
| Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД.
Мы с вами говорим об одном и том же. В статье как раз и указывается, что мы можем распараллелить всё, кроме базы данных — именно в ней и происходит синхронизация.
| Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Извините, но вы не вникли в суть вопроса: мы именно обсуждаем взаимодействие фреймворка с базой данных И говорим, что именно накладные расходы на такое взаимодействие съедают все возможности современной техники
Мы с вами говорим об одном и том же. В статье как раз и указывается, что мы можем распараллелить всё, кроме базы данных — именно в ней и происходит синхронизация.
| Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Извините, но вы не вникли в суть вопроса: мы именно обсуждаем взаимодействие фреймворка с базой данных И говорим, что именно накладные расходы на такое взаимодействие съедают все возможности современной техники
Судя по отрицательному отношению к статье, можно сделать вывод, что сейчас лучше отказаться от использования маппирования файлов в память. При этом наш высоконагруженный сервер приложений должен при загрузке потратит некоторое время на кэширование данных из базы данных. Зато потом он будет работать очень быстро и при этом мы по прежнему будем вести разработку в 64-битном режиме на защищённом языке программирования: Java, C# и т.п.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скорость работы корпоративных приложений