А насколько реально получить с дрона стереопару (от двух камер или благодаря движению) и определить расстояние до стен по ней. Просто я когда-то писал программу сопоставления кадров стереопары и пришел к красивому быстрому алгоритму (и простому как две копейки). Интересно было бы наконец-то его применить.
Так можно про всё что угодно сказать. А где конструктивные комментарии? — нету. Где комментарий о том, что в четвёртом фреймворке появилась возможность маппирования сверхбольших файлов? — нету… Где предложения попытаться что-нть сделать? — тоже нету… Плохо, очень плохо…
| Все эти 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-а. Так что достоверность данных из статьи в очередной раз подтвердилась.
Тем не менее кто-нибуть предоставит более высокие данные — буду рад посмотреть, как ему удалось их получить.
Вы правильно подметили, что узким местом является база данных. Нехило округляя, мы тем самым даём большую фору системам управления базам данных. И даже с такой форой базы данных оказываются очень медлительными на фоне настоящих возможностей современной техники.
1) ну да, слово «модные» не совсем удачное, можно вместо него читать «распространённые»
2) точная фраза «в нынешнем виде они непригодны для разработки в будущем»
Ну вы сравните 100 тысяч и 100 миллионов — разница в три порядка. И округление в 50 000 на фоне такой разницы (кстати, в пользу баз данных) не имеет большого значения.
| Проверено как раз на АБСке одного крупного производителя в ритейле
Извиняюсь, за возможно некорректный вопрос… Хотелось бы оценить объём данных, с которыми приходится работать ритейлу. Т.е. интересно, на сколько гигабайт растёт база в год и на сколько гигабайт растёт размер сжатого архива этой базы (для оценки фактического объёма данных в базе)
Я обобщил результаты работы по расшиванию узких мест в своих проектах, сделал выводы и изложил их здесь. Если у кого-то другие данные, буду рад увидеть и узнать, как вы этого добились.
Мы с вами говорим об одном и том же. В статье как раз и указывается, что мы можем распараллелить всё, кроме базы данных — именно в ней и происходит синхронизация.
| Статья посвящена исследованию взаимодействия конкретного фреймворка с БД.
Извините, но вы не вникли в суть вопроса: мы именно обсуждаем взаимодействие фреймворка с базой данных И говорим, что именно накладные расходы на такое взаимодействие съедают все возможности современной техники
Не подскажете, можно ли в 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-а. Так что достоверность данных из статьи в очередной раз подтвердилась.
Тем не менее кто-нибуть предоставит более высокие данные — буду рад посмотреть, как ему удалось их получить.
2) точная фраза «в нынешнем виде они непригодны для разработки в будущем»
Извиняюсь, за возможно некорректный вопрос… Хотелось бы оценить объём данных, с которыми приходится работать ритейлу. Т.е. интересно, на сколько гигабайт растёт база в год и на сколько гигабайт растёт размер сжатого архива этой базы (для оценки фактического объёма данных в базе)