How to become an author
Search
Write a publication
Pull to refresh

Comments 49

Мне кажется, что автор данного топика не совсем понимает, о чем ведет речь.
Total votes 33: ↑32 and ↓1+31
Я обобщил результаты работы по расшиванию узких мест в своих проектах, сделал выводы и изложил их здесь. Если у кого-то другие данные, буду рад увидеть и узнать, как вы этого добились.
Total votes 2: ↑1 and ↓10
К сожалению, нынче модные интерпретируемые и полуинтерпретируемые языки программирования, такие как C#, 1C, Java, не имеют средств, для прямой работы с памятью, поэтому в нынешнем виде они непригодны для разработки в будущем.

Вообще-то всякие маленькие базы данных типа SqlCE работают in-process с приложением — не важно на чем оно написано. Тут скорее не язык должен это поддерживать, а сама база данных.
Total votes 1: ↑1 and ↓0+1
Ну и справедливости ради: c# и java уже давно не интерпретируемые, потому и достаточно шустрые. А процедуры на них (соответственно в mssql и oracle/postgres) работают с объектом соединения фактически на разделяемой памяти, что опять же не может положительно сказываться на производительности. Ну и массированную запись опять таки можно распараллелить по какому-либо показателю между серверами приложений. Точно так же с выборкой. — таблицы кластеризуются например по годам. Проверено как раз на АБСке одного крупного производителя в ритейле
Total votes 5: ↑5 and ↓0+5
UFO just landed and posted this here
Да, конечно. Прошу прощения — когда писал комментарий, запамятовал это слово.
This comment wasn’t rated yet0
Поэтому я их назвал «полуинтерпретируемыми»
Total votes 2: ↑0 and ↓2-2
Дважды компилируемые все же, имхо. Сначала в промежуточный код при сборке, а при запуске jit-ятся в процессорозависимый.
Total votes 2: ↑2 and ↓0+2
| Проверено как раз на АБСке одного крупного производителя в ритейле

Извиняюсь, за возможно некорректный вопрос… Хотелось бы оценить объём данных, с которыми приходится работать ритейлу. Т.е. интересно, на сколько гигабайт растёт база в год и на сколько гигабайт растёт размер сжатого архива этой базы (для оценки фактического объёма данных в базе)
Total votes 3: ↑2 and ↓1+1
Какая-то каша.
Хотя если считать основной мысль о том, что неплохо бы ОРМ совершить некоторый эволюционный скачок, то я соглашусь.
Совсем не раскрыта роль кэшей, а без них в тяжелых приложениях никак. Ну и NoSQL решения уже давно шагают по планете, на них хотя бы можно переложить сбор внутренней статистики и протоколирование некритичных операций.

Разговаривать про некие «общесистемные» пороги ограничений бессмысленно, пока речь не идет о конкретной архитектуре, конкретной БД с ее скоростью индексов, и конкретных ресурсах. Какие-то ограничения относительно БД всегда будут и проблема их существования решается архитектурно, путем балансированием в пределах CAP в соответствии с задачами.
Total votes 3: ↑3 and ↓0+3
Интересуют тесты в результате которых получены цифры и конфигурация железо\СУБД
Total votes 2: ↑2 and ↓0+2
Статья в которой читатель узнаёт, что 1С это нынче модный язык программирования, но у него как и Java с 1С нет никаких шансов в будущем.
Total votes 11: ↑11 and ↓0+11
1) ну да, слово «модные» не совсем удачное, можно вместо него читать «распространённые»
2) точная фраза «в нынешнем виде они непригодны для разработки в будущем»
Total votes 2: ↑0 and ↓2-2
UFO just landed and posted this here
Разумеется, красивых цифр не бывает. Разумеется, на разных системах были разные данные. Напрмер, в статье приведены данные, о том, что Oracle строит индекс по 1 млн элементов за 20 секунд, т.е. 50 000 строк в секунду. Тем не менее, я оцениваю этот показатель в 100 000 строк в секунду. Естесственно, при таком округлении не имеет значение, было ли там 20 секунд или 22 секунду. На смысл статьи это не влияет. FireBird строит индексы, например, со скоростью 20 000 строк в секунду. И это самый большой недостаток этой базы данных, с которой мне пришлось несколько лет работать. Процессор Pentium III 1000 МГц 1 Гб ОЗУ строит индекс по 100 млн элементов за 0,54 — это данные, которые я получил сам в далёком 2003-м году.
Надо сказать, что я оценивал качество своих тестов, сравнивая достигнутые результаты с результатами у других людей. И у других цифры были гораздо ниже.
Total votes 2: ↑1 and ↓10
>«Oracle строит индекс по 1 млн элементов за 20 секунд, т.е. 50 000 строк в секунду. Тем не менее, я оцениваю этот показатель в 100 000 строк в секунду» — я чего-то догоняю
Total votes 1: ↑1 and ↓0+1
Ну вы сравните 100 тысяч и 100 миллионов — разница в три порядка. И округление в 50 000 на фоне такой разницы (кстати, в пользу баз данных) не имеет большого значения.
Total votes 3: ↑2 and ↓1+1
Логика статьи мне непонятна. Тесты приводим по одним объемам, рассуждаем о других. При этом не скромно «округляя». И какой смысл рассуждать о размещении бизнес логики, всяких джавах и сишарпах, когда фиксация в БД является узким горлышком и, собственно, определяет тему топика?
Total votes 2: ↑2 and ↓0+2
Вы правильно подметили, что узким местом является база данных. Нехило округляя, мы тем самым даём большую фору системам управления базам данных. И даже с такой форой базы данных оказываются очень медлительными на фоне настоящих возможностей современной техники.
Total votes 3: ↑2 and ↓1+1
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

И нельзя, нельзя сравнивать построение индекса и скорость сортировки. Индекс это построение сбалансированного двоичного дерева, цель которого — увеличение скорости доступа к данным. Это куда больше чем просто получение отсортированного набора данных. Если вы попытаетесь самостоятельно построить двоичное дерево, пусть и без сброса на диск, лишь в оперативе, я полагаю вам придется изрядно потрудиться, чтобы таки померяться с ораклом.
Total votes 3: ↑3 and ↓0+3
>Особенность применения ООП в том, что оно порождает кучу мелких >обращений к базе данных.
Кучу мелких запросов в БД делает неопытный программист, и не важно какой подход к разработке применяется.
Total votes 12: ↑12 and ↓0+12
ООП поощряет неопытного программиста к созданию кучи мелких запросов, а у опытных не всегда есть время, чтобы помогать исправлять такие вещи
Total votes 3: ↑0 and ↓3-3
При чем здесь ООП вообще? Каким образом оно что-либо поощряет? В конструкторе объектов по дефолту зашито обращение к БД?
ООП и БД — это абсолютно разные, непересекающиеся, друг от друга независимые вещи.

При прочтении статьи у меня сложилось впечатление, что ваша профессия — системный аналитик, консультант или что-либо наподобие, потому что (моё мнение) вы никогда не писали код. Вы не являетесь специалистом по Java, C#, теории языков программирования, вы не знаете, что такое JIT компиляция и т.д.
8000 SQL-запросов за секунду

Что это за цифра? Откуда она взялась, какие конкретно запросы вы имели ввиду, какая СУБД, какое железо, какой совокупный объем данных, какие индексы БД?

В общем для того, чтоб делать ТАКИЕ громкие заявления, в статье не хватает аргументов.
Total votes 3: ↑3 and ↓0+3
1) При чём здесь ООП
ООП, за 30 лет своего существования, подтвердило свою эффективность. Поэтому всегда стараются писать в объектном стиле, даже если программируют для реляционных баз данных.

2) Каким образом ООП поощряет к созданию кучи мелких запросов
Вы правильно отметили, что ООП и БД это разные вещи и они сложно друг с другом сочетаются. Давайте рассмотрим случай, когда есть два класса: «книга» и «автор». У автора есть поле «Имя». У книги есть «Название» и ссылка на автора. Предполагается, что если вы пишете на объектно-ориентированном языке, то вывод списка книг с именами авторов будет выглядеть примерно следующим образом

for (int i=0; i<books_count; i++)
{
print ("%s %s", book[i].name, books[i].autor.name);
}


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

3) Про 8000 строк — подобный вопрос уже был, я на него ответил ниже. Это число было получено в результате очень сильной оптимизации алгоритмов репликации данных между серверами

4) Про «ТАКИЕ громкие заявления»
Выводы напрямую следуют из цифр, полученных в результате тестов. Для того чтобы сделать другой вывод нужно либо найти ошибку в цепочке логиечских рассуждений, либо показать, что цифры неверны.

Total votes 6: ↑1 and ↓5-4
Охренеть.
Ну если мозги отключить и выбросить, то да. Но это ещё постараться надо.
Total votes 1: ↑1 and ↓0+1
При чем здесь ООП вообще?


ООП это прежде всего подход. Подход, при котором еденица воздействия — объект. Если мы попытаемся применить этот подход к обработке больших массивов данных, мы будем вынуждены работать не с множествами объектов, а с каждым объектом по отдельности.

ООП и БД — это абсолютно разные, непересекающиеся, друг от друга независимые вещи.

Абсолютно верно. Но в последнее время действительно имеется тенденция применения объектной парадигмы при работе и с реляционными данными. Многие фреймворки маскируют реляционный слой, предоставляя его ОО обертку. 1С — прекрасный тому пример.
Total votes 2: ↑1 and ↓10
> поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.
Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?

> даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду
> сетевом взаимодействии задействовано ещё больше процессов, соответственно и число запросов уменьшается практически до 1000.
Очень интересно узнать: как измеряли/считали?
Total votes 2: ↑2 and ↓0+2
>> поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.
> Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?

здесь видимо претензия к тому что, я включил в список на распараллеливание сервер приложений. Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.

>Очень интересно узнать: как измеряли/считали
Данные получены в результате работы над системами репликации данных между серверами баз данных. Достоверность данных проверялась, путём сопоставления с даннымми из других источников.
Например только сегодня появилась статья:
habrahabr.ru/post/139708/
В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а. Так что достоверность данных из статьи в очередной раз подтвердилась.

Тем не менее кто-нибуть предоставит более высокие данные — буду рад посмотреть, как ему удалось их получить.
Total votes 3: ↑1 and ↓2-1
Скорость работы корпоративных приложений вообще не зависит ни от языка, ни от компилятора, ни от базы данных. У них сложность высокая, описанные в статье факты не занимают и десятка процентов от общей сложности.

На этом же сайте есть блог ЕРП, он как раз про корпоративные приложения. Статей непосредственно по коду или скриптам там практически нет, именно по вышеописанной причине.
Total votes 1: ↑1 and ↓0+1
Да, верно, скорость работы корпоративных приложений практически не зависит ни от языка программирования, ни от базы данных. Узким местом, как это и показано в статье, является связь между «языком программирования» и базой данных. И чтобы это узкое место убрать, нужно либо логику разместить внутри базы данных, либо базу данных разместить внутри сервера приложений. Оба этих метода в статье рассмотрены.
Total votes 1: ↑0 and ↓1-1
раз ни база ни язык программирования не являются узким местом то и не важно что там между ними происходит.

Статья из раздела «Я сам даже маленькую бухгалтерию не написал но сейчас буду рассказывать как это делать правильно».
Total votes 2: ↑2 and ↓0+2
Тесты показывают, что вы ошибаетесь, и накладные расходы на взаимодействие очень велики.
Total votes 1: ↑0 and ↓1-1
нет тут никаких тестов. Повторюсь:

Статья из раздела «Я сам даже маленькую бухгалтерию не написал но сейчас буду рассказывать как это делать правильно»
Total votes 2: ↑2 and ↓0+2
Вы не доверяете каким-то цифрам? — давайте перепроверим…
Total votes 1: ↑0 and ↓1-1
Что перепроверять-то? Вот утверждение из текста:

Значит, даже если сервер приложений и база данных находятся на одном компьютере, то из-за накладных расходов времени, мы не можем рассчитывать на выполнение более 8000 SQL-запросов за секунду.

да легко SQL-сервер может выполнять 8000 SQL-запросов в секунду. На хабре полно людей которые с такой нагрузкой работают. Вот и всё.

Для справки
— результат запроса может кешироваться SQL-сервером
— отдельные части результатов запроса могут кешироваться и объединяться
— данные могут кешироваться в памяти
— план запроса SQL-сервером строится как в зависимости от данных так и в зависимости от нагрузки

И это при том что само использование термина запрос в таком контексте некорректно т.к. запросы могут выполняться мгновенно а могут расчитываться в течении пары суток.
Total votes 2: ↑2 and ↓0+2
Вы можете себе представить, чтоб ваш SQL-сервер выполнял 100 млн запросов в секунду? Нет? — вот об этом и идёт речь. Никто не спорит, и в статье об этом говорится, что в результате различных оптимизаций SQL-сервер можно разогнать до 100 тысяч запросов в секунду. Но 100 миллионов ему не по зубам.
Total votes 2: ↑0 and ↓2-2
При желании можно и один запрос написать который завалит сервер.

Дурное дело нехитрое.
Total votes 1: ↑1 and ↓0+1
Так можно целую серию статей написать %) «Почему нельзя читать со скоростью 100 млн знаков/с», «Почему коты не бегают со скоростью 100 млн км/ч»…

«Можно повысить общую скорость путём кластеризации» это и есть те самые различные очень тонкие способы оптимизации?
Total votes 1: ↑1 and ↓0+1
Посмотрел ваш профиль…

Не подскажете, можно ли в Java каким-либо образом организовать маппирование файла в память. Например, через native-интерфейс вызвать системную функцию по маппингу файла и потом каким-либо образом работать с выделенным участком адрессного пространства как с обычным Java-массивом.
Total votes 3: ↑0 and ↓3-3
С вашим выводом я, в общем и целом, согласен, как и с некоторыми тезисами.

Применение парадигмы ООП действительно существенно увеличивает показатель запросов/секунду. Закрытие периода выполненное в традициях этого подхода, действительно заспамит базу данных запросами. В то же время можно и обойтись десятком — другим запросов, но это уже больше ближе к выносу логики на сторону сервера.

Однако подводка… действительно заставляет недоумевать.

Разумное зерно в вашей статье безусловно есть. Но оно далеко не на поверхности. И от него очень отвлекают спорно сформулированные тезисы и сферические цифры в вакууме.

Думаю, люди вас просто не поняли — очень подкачало изложение.
Total votes 3: ↑2 and ↓1+1
Спасибо. Как говорится, первый блин…
Total votes 2: ↑1 and ↓10
> Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.
Независимые друг от друга запросы мало кому нужны, обычно хочется чтобы после обновления баланса одной тётенькой-бухгалтером его и остальные увидели обновлённым. Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД. Соответственно они и всплывают все и сразу на этом уровне.

> В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а.
Автор занимался не тестированием РДБ, тем более что выборка ведётся из служебной таблицы содержимое которой даже ен приведено в статье, а запись даже не рассматривалась. Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.

Взгляните ещё раз внимательно проблему которую пытаетесь рассмотреть в статье — она состоит из нескольких очень ортогональных частей. Вы пытаетесь свалить всё в кучу и решить оптом, это очень-очень сложно.
This comment wasn’t rated yet0
| Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД.

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

| Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.

Извините, но вы не вникли в суть вопроса: мы именно обсуждаем взаимодействие фреймворка с базой данных И говорим, что именно накладные расходы на такое взаимодействие съедают все возможности современной техники
This comment wasn’t rated yet0
Судя по отрицательному отношению к статье, можно сделать вывод, что сейчас лучше отказаться от использования маппирования файлов в память. При этом наш высоконагруженный сервер приложений должен при загрузке потратит некоторое время на кэширование данных из базы данных. Зато потом он будет работать очень быстро и при этом мы по прежнему будем вести разработку в 64-битном режиме на защищённом языке программирования: Java, C# и т.п.
Total votes 1: ↑0 and ↓1-1
Да ладно, все проще, можно сделать вывод что написана ахинея %)
This comment wasn’t rated yet0
Так можно про всё что угодно сказать. А где конструктивные комментарии? — нету. Где комментарий о том, что в четвёртом фреймворке появилась возможность маппирования сверхбольших файлов? — нету… Где предложения попытаться что-нть сделать? — тоже нету… Плохо, очень плохо…
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr