В dos-игрушке f19 расчет гравитации тоже делался таким способом. В результате из-за накапливаемой ошибки можно было летать совсем без топлива регулярно делая горки
Мне интересно, насколько имеет смысл использовать асинхронность в Python ? - большинство библиотек здесь синхронны. Кроме того, не являются асинхронными ни СУБД, ни "жёсткие" диски.
А что, если wifi-6 клиенты перевести на 2,4G, а wifi-5 - на 5G ? - тогда и устройства разных стандартов мешать друг другу не будут и дальность у ax увеличится. А скорости в 400мбит хватает... если соседи диапазон не забили..
А насколько реально получить с дрона стереопару (от двух камер или благодаря движению) и определить расстояние до стен по ней. Просто я когда-то писал программу сопоставления кадров стереопары и пришел к красивому быстрому алгоритму (и простому как две копейки). Интересно было бы наконец-то его применить.
Так можно про всё что угодно сказать. А где конструктивные комментарии? — нету. Где комментарий о том, что в четвёртом фреймворке появилась возможность маппирования сверхбольших файлов? — нету… Где предложения попытаться что-нть сделать? — тоже нету… Плохо, очень плохо…
| Все эти JSF, MVC, Rails и прочие по умолчанию переносят все проблемы синхронизации и межпроцессного взаимодействия на БД.
Мы с вами говорим об одном и том же. В статье как раз и указывается, что мы можем распараллелить всё, кроме базы данных — именно в ней и происходит синхронизация.
| Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Извините, но вы не вникли в суть вопроса: мы именно обсуждаем взаимодействие фреймворка с базой данных И говорим, что именно накладные расходы на такое взаимодействие съедают все возможности современной техники
Судя по отрицательному отношению к статье, можно сделать вывод, что сейчас лучше отказаться от использования маппирования файлов в память. При этом наш высоконагруженный сервер приложений должен при загрузке потратит некоторое время на кэширование данных из базы данных. Зато потом он будет работать очень быстро и при этом мы по прежнему будем вести разработку в 64-битном режиме на защищённом языке программирования: Java, C# и т.п.
Вы можете себе представить, чтоб ваш SQL-сервер выполнял 100 млн запросов в секунду? Нет? — вот об этом и идёт речь. Никто не спорит, и в статье об этом говорится, что в результате различных оптимизаций SQL-сервер можно разогнать до 100 тысяч запросов в секунду. Но 100 миллионов ему не по зубам.
Не подскажете, можно ли в Java каким-либо образом организовать маппирование файла в память. Например, через native-интерфейс вызвать системную функцию по маппингу файла и потом каким-либо образом работать с выделенным участком адрессного пространства как с обычным Java-массивом.
Да, верно, скорость работы корпоративных приложений практически не зависит ни от языка программирования, ни от базы данных. Узким местом, как это и показано в статье, является связь между «языком программирования» и базой данных. И чтобы это узкое место убрать, нужно либо логику разместить внутри базы данных, либо базу данных разместить внутри сервера приложений. Оба этих метода в статье рассмотрены.
1) При чём здесь ООП
ООП, за 30 лет своего существования, подтвердило свою эффективность. Поэтому всегда стараются писать в объектном стиле, даже если программируют для реляционных баз данных.
2) Каким образом ООП поощряет к созданию кучи мелких запросов
Вы правильно отметили, что ООП и БД это разные вещи и они сложно друг с другом сочетаются. Давайте рассмотрим случай, когда есть два класса: «книга» и «автор». У автора есть поле «Имя». У книги есть «Название» и ссылка на автора. Предполагается, что если вы пишете на объектно-ориентированном языке, то вывод списка книг с именами авторов будет выглядеть примерно следующим образом
примерно так пишут в учебниках. Теперь, если мы используем объектную надстройку над реляционной базой данных, то мы также можем получить список книг ввиде массива. Но в этом массиве не будет имени автора, а для того чтобы его получить, такая программа будет на каждой итерации цикла порождать SQL запрос к базе для получения имени одного единственного автора.
Вот таким образом ООП и поощряет новичков на порождение кучи мелких запросов.
3) Про 8000 строк — подобный вопрос уже был, я на него ответил ниже. Это число было получено в результате очень сильной оптимизации алгоритмов репликации данных между серверами
4) Про «ТАКИЕ громкие заявления»
Выводы напрямую следуют из цифр, полученных в результате тестов. Для того чтобы сделать другой вывод нужно либо найти ошибку в цепочке логиечских рассуждений, либо показать, что цифры неверны.
>> поскольку мы всегда можем поставить рядом ещё один сервер и распараллелить сервера приложений и веб-сервера.
> Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?
здесь видимо претензия к тому что, я включил в список на распараллеливание сервер приложений. Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.
>Очень интересно узнать: как измеряли/считали
Данные получены в результате работы над системами репликации данных между серверами баз данных. Достоверность данных проверялась, путём сопоставления с даннымми из других источников.
Например только сегодня появилась статья: habrahabr.ru/post/139708/
В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а. Так что достоверность данных из статьи в очередной раз подтвердилась.
Тем не менее кто-нибуть предоставит более высокие данные — буду рад посмотреть, как ему удалось их получить.
В dos-игрушке f19 расчет гравитации тоже делался таким способом. В результате из-за накапливаемой ошибки можно было летать совсем без топлива регулярно делая горки
Это не интерференционная картина - это изображение волн на воде.
Мне интересно, насколько имеет смысл использовать асинхронность в Python ? - большинство библиотек здесь синхронны. Кроме того, не являются асинхронными ни СУБД, ни "жёсткие" диски.
Недавно наткнулся на то что std::map в Visual Studio C++ крайне медленный. Причём в C# он работает прекрасно.
А что, если wifi-6 клиенты перевести на 2,4G, а wifi-5 - на 5G ? - тогда и устройства разных стандартов мешать друг другу не будут и дальность у ax увеличится. А скорости в 400мбит хватает... если соседи диапазон не забили..
Мы с вами говорим об одном и том же. В статье как раз и указывается, что мы можем распараллелить всё, кроме базы данных — именно в ней и происходит синхронизация.
| Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Извините, но вы не вникли в суть вопроса: мы именно обсуждаем взаимодействие фреймворка с базой данных И говорим, что именно накладные расходы на такое взаимодействие съедают все возможности современной техники
Не подскажете, можно ли в Java каким-либо образом организовать маппирование файла в память. Например, через native-интерфейс вызвать системную функцию по маппингу файла и потом каким-либо образом работать с выделенным участком адрессного пространства как с обычным Java-массивом.
ООП, за 30 лет своего существования, подтвердило свою эффективность. Поэтому всегда стараются писать в объектном стиле, даже если программируют для реляционных баз данных.
2) Каким образом ООП поощряет к созданию кучи мелких запросов
Вы правильно отметили, что ООП и БД это разные вещи и они сложно друг с другом сочетаются. Давайте рассмотрим случай, когда есть два класса: «книга» и «автор». У автора есть поле «Имя». У книги есть «Название» и ссылка на автора. Предполагается, что если вы пишете на объектно-ориентированном языке, то вывод списка книг с именами авторов будет выглядеть примерно следующим образом
for (int i=0; i<books_count; i++)
{
print ("%s %s", book[i].name, books[i].autor.name);
}
примерно так пишут в учебниках. Теперь, если мы используем объектную надстройку над реляционной базой данных, то мы также можем получить список книг ввиде массива. Но в этом массиве не будет имени автора, а для того чтобы его получить, такая программа будет на каждой итерации цикла порождать SQL запрос к базе для получения имени одного единственного автора.
Вот таким образом ООП и поощряет новичков на порождение кучи мелких запросов.
3) Про 8000 строк — подобный вопрос уже был, я на него ответил ниже. Это число было получено в результате очень сильной оптимизации алгоритмов репликации данных между серверами
4) Про «ТАКИЕ громкие заявления»
Выводы напрямую следуют из цифр, полученных в результате тестов. Для того чтобы сделать другой вывод нужно либо найти ошибку в цепочке логиечских рассуждений, либо показать, что цифры неверны.
> Вы научились распараллельвать произвольный алгоритм на произвольное число узлов? ACM в курсе?
здесь видимо претензия к тому что, я включил в список на распараллеливание сервер приложений. Здесь имеется ввиду то, что если вы программируете JSP/JSF или ASP.Net, или PHP (а именно на них в большинстве случаев идёт разработка), то как правило все веб-запросы выполняются независимо друг от друга. Поэтому, если вы специально не блокировали такую возможность, вы можете к одной базе данных подключить несколько веб серверов с серверами приложений.
>Очень интересно узнать: как измеряли/считали
Данные получены в результате работы над системами репликации данных между серверами баз данных. Достоверность данных проверялась, путём сопоставления с даннымми из других источников.
Например только сегодня появилась статья:
habrahabr.ru/post/139708/
В ней автор с седьмой попытки выжал «1000» запросов в секунду из FireBird-а. Так что достоверность данных из статьи в очередной раз подтвердилась.
Тем не менее кто-нибуть предоставит более высокие данные — буду рад посмотреть, как ему удалось их получить.