crypto5 wrote:
Это вы ерундой занимаетесь ИМХО, уже есть отлично оптимизированный C/C++ код внутри sql сервера, с кешами, умной статистикой и т.д. Чем он вам не подходит?
да обсуждали уже, там оказывается что SQL далеко не такой уж и умный. Например что такое для C++ найти значение в табличке из миллиона записей?
SQL над такими вещами задумывается по 0.2 секунды
OtherSide wrote:
SQL над такими вещами задумывается по 0.2 секунды
Что, сам язык задумывается, вне зависимости от базы данных?
Ну а вообще да, скорее всего локальный lookup в памяти - будет быстрее, никто не спорит. А вот если вы несколько нодов засунете для своего проекта, воткнете что-то вроде distributed cache (тот же memcached), то все может быстрее забегать.
crypto5 wrote:
Это вы ерундой занимаетесь ИМХО, уже есть отлично оптимизированный C/C++ код внутри sql сервера, с кешами, умной статистикой и т.д. Чем он вам не подходит?
+1
а я не согласен, к mssql запрос по индексу - это где-то 150 запросов в секунду, это далеко не всегда достаточно
все крупные проекты имеют C++ кеши отдельно от базы (ссылку не дам, поищите, есть статья об архитектуре наиболее популярных веб-проектов)
Я думаю где то ближе к тыс если все в памяти лежит. В кешах проекты частенько держат отрендеренные страницы и денормализированные и отрендеренные данные
OtherSide wrote:
SQL над такими вещами задумывается по 0.2 секунды
Что, сам язык задумывается, вне зависимости от базы данных?
Ну а вообще да, скорее всего локальный lookup в памяти - будет быстрее, никто не спорит. А вот если вы несколько нодов засунете для своего проекта, воткнете что-то вроде distributed cache (тот же memcached), то все может быстрее забегать.
И что, хотите сказать такие вещи на PHP будут работать так же быстро как на C++ скажем?
crypto5 wrote:
Это вы ерундой занимаетесь ИМХО, уже есть отлично оптимизированный C/C++ код внутри sql сервера, с кешами, умной статистикой и т.д. Чем он вам не подходит?
да обсуждали уже, там оказывается что SQL далеко не такой уж и умный. Например что такое для C++ найти значение в табличке из миллиона записей?
SQL над такими вещами задумывается по 0.2 секунды
OtherSide wrote:
SQL над такими вещами задумывается по 0.2 секунды
Что, сам язык задумывается, вне зависимости от базы данных?
Ну а вообще да, скорее всего локальный lookup в памяти - будет быстрее, никто не спорит. А вот если вы несколько нодов засунете для своего проекта, воткнете что-то вроде distributed cache (тот же memcached), то все может быстрее забегать.
И что, хотите сказать такие вещи на PHP будут работать так же быстро как на C++ скажем?
crypto5 wrote:
Это вы ерундой занимаетесь ИМХО, уже есть отлично оптимизированный C/C++ код внутри sql сервера, с кешами, умной статистикой и т.д. Чем он вам не подходит?
+1
а я не согласен, к mssql запрос по индексу - это где-то 150 запросов в секунду, это далеко не всегда достаточно
все крупные проекты имеют C++ кеши отдельно от базы (ссылку не дам, поищите, есть статья об архитектуре наиболее популярных веб-проектов)
Я думаю где то ближе к тыс если все в памяти лежит. В кешах проекты частенько держат отрендеренные страницы и денормализированные и отрендеренные данные
если про mssql не уверен, что 1000 будет, меньше скорее всего
но никто не запрещает денормализованные данные и в базе хранить (пусть и в промежуточной), но так никто не делает по соображениям производительности
crypto5 wrote:
Это вы ерундой занимаетесь ИМХО, уже есть отлично оптимизированный C/C++ код внутри sql сервера, с кешами, умной статистикой и т.д. Чем он вам не подходит?
+1
а я не согласен, к mssql запрос по индексу - это где-то 150 запросов в секунду, это далеко не всегда достаточно
все крупные проекты имеют C++ кеши отдельно от базы (ссылку не дам, поищите, есть статья об архитектуре наиболее популярных веб-проектов)
Я думаю где то ближе к тыс если все в памяти лежит. В кешах проекты частенько держат отрендеренные страницы и денормализированные и отрендеренные данные
если про mssql не уверен, что 1000 будет, меньше скорее всего
но никто не запрещает денормализованные данные и в базе хранить (пусть и в промежуточной), но так никто не делает по соображениям производительности
а я не согласен, к mssql запрос по индексу - это где-то 150 запросов в секунду, это далеко не всегда достаточно
все крупные проекты имеют C++ кеши отдельно от базы (ссылку не дам, поищите, есть статья об архитектуре наиболее популярных веб-проектов)
Я думаю где то ближе к тыс если все в памяти лежит. В кешах проекты частенько держат отрендеренные страницы и денормализированные и отрендеренные данные
если про mssql не уверен, что 1000 будет, меньше скорее всего
но никто не запрещает денормализованные данные и в базе хранить (пусть и в промежуточной), но так никто не делает по соображениям производительности
От задачи зависит. Вполне себе можно хранить.
в высоконагруженных проектах не хранят, либо хранят то, что не так часто используется
Alexandr wrote:
а я не согласен, к mssql запрос по индексу - это где-то 150 запросов в секунду, это далеко не всегда достаточно
все крупные проекты имеют C++ кеши отдельно от базы (ссылку не дам, поищите, есть статья об архитектуре наиболее популярных веб-проектов)
Я думаю где то ближе к тыс если все в памяти лежит. В кешах проекты частенько держат отрендеренные страницы и денормализированные и отрендеренные данные
если про mssql не уверен, что 1000 будет, меньше скорее всего
но никто не запрещает денормализованные данные и в базе хранить (пусть и в промежуточной), но так никто не делает по соображениям производительности
От задачи зависит. Вполне себе можно хранить.
в высоконагруженных проектах не хранят, либо хранят то, что не так часто используется
Ну раз все программисты высоконагруженных проектов вам отчитываются, то конечно спорить не буду..
crypto5 wrote:
Это вы ерундой занимаетесь ИМХО, уже есть отлично оптимизированный C/C++ код внутри sql сервера, с кешами, умной статистикой и т.д. Чем он вам не подходит?
да обсуждали уже, там оказывается что SQL далеко не такой уж и умный. Например что такое для C++ найти значение в табличке из миллиона записей?
SQL над такими вещами задумывается по 0.2 секунды
Если на таблице есть индекс то 0.2 сек явно много
Табличка на 6 млрд записей, под каждый запрос новый индекс не повесишь...
crypto5 wrote:
Это вы ерундой занимаетесь ИМХО, уже есть отлично оптимизированный C/C++ код внутри sql сервера, с кешами, умной статистикой и т.д. Чем он вам не подходит?
да обсуждали уже, там оказывается что SQL далеко не такой уж и умный. Например что такое для C++ найти значение в табличке из миллиона записей?
SQL над такими вещами задумывается по 0.2 секунды
Если на таблице есть индекс то 0.2 сек явно много
Табличка на 6 млрд записей, под каждый запрос новый индекс не повесишь...
mudi wrote:Какой странный опрос. Надо в разделе "Автомобили" тоже так спросить:
На чем вы ездите:
[ ] Corolla
[ ] Бежевая Кэмри
[ ] Другое
По теме вашего опроса: программирую на C++, перспективмым считаю его же, а также Python и Java.
+1
Кому-то нужен трак, кому-то мотоцикл, кому-то бежевая Кэмри, и они все могут быть одновременно перспективны. Я пишу на низком уровне на C++, на высоком - на Python, и то и другое хорошие языки с разными нишами. PHP тоже вроде бы нормальный язык, только ниша другая и не пересекающаяся ни с C++, ни с Python. Ruby это просто альтернатива Python. Ruby лучше как язык, но в Python больше выбор библиотек.
Вот Java и C# это, по-моему, совершенно бесполезные языки - ни рыба ни мясо.
crypto5 wrote:Ну раз все программисты высоконагруженных проектов вам отчитываются, то конечно спорить не буду..
причем тут все программисты, посмотрите статейку как устроены наиболее нагруженные веб-проекты
никто не говорит, что если тупо-базы хватает, то нужно дополнительный огород городить
crypto5 wrote:Ну раз все программисты высоконагруженных проектов вам отчитываются, то конечно спорить не буду..
причем тут все программисты, посмотрите статейку как устроены наиболее нагруженные веб-проекты
никто не говорит, что если тупо-базы хватает, то нужно дополнительный огород городить
crypto5 wrote:Ну раз все программисты высоконагруженных проектов вам отчитываются, то конечно спорить не буду..
причем тут все программисты, посмотрите статейку как устроены наиболее нагруженные веб-проекты
никто не говорит, что если тупо-базы хватает, то нужно дополнительный огород городить
И там в статьях будут схемы БД?
вы правда считаете, что linkedin, myspace, livejournal и одноклассники писали настолько бездари, что не разбираются в базе данных и от незнания в С++ полезли?
crypto5 wrote:Ну раз все программисты высоконагруженных проектов вам отчитываются, то конечно спорить не буду..
причем тут все программисты, посмотрите статейку как устроены наиболее нагруженные веб-проекты
никто не говорит, что если тупо-базы хватает, то нужно дополнительный огород городить
И там в статьях будут схемы БД?
вы правда считаете, что linkedin, myspace, livejournal и одноклассники писали настолько бездари, что не разбираются в базе данных и от незнания в С++ полезли?
Нет, я ,правда, так не считаю, но это как то относится к вопросу денормализации БД?
Last edited by crypto5 on 13 Nov 2012 09:26, edited 1 time in total.
crypto5 wrote:
Возвращаемся к разговору про преагрегации.
Блин. Преагрегации есть. Все работает ОК. Только мне ходит пока 500 чел в день всего. Если будет 10 000 думаю переходить на С++
Проще будет железа докупить и еще нодов воткнуть. Потому как не факт, что на С++ вы сделаете лучше/быстрее уже готовых решений в виде баз данных. И уж тем более не факт, что вы это сделаете в какие-то приемлемые сроки. Как тут правильно заметили, на С++ можно конечно специализированный код написать, который будет быстрее работать, чем существующие БД. Даже в пример всякие linkedin и прочие фейсбуки приводят. Только там и людей намного больше над этим работают (а многие из этих людей, с солидным опытом разработки подобных систем).
Кстати, Adobe Premiere Pro и Adode After Effects - таки написаны на C++, unmanaged code.
И без всякой смеси managed/unmanaged, которую так любит M$
редкий пример чистых C++ продуктов
За счет этого они работают только под 64bit (это не ограничение - After Effects вообще память начинается с 8Gb и до бесконечности )
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
crypto5 wrote:
Возвращаемся к разговору про преагрегации.
Блин. Преагрегации есть. Все работает ОК. Только мне ходит пока 500 чел в день всего. Если будет 10 000 думаю переходить на С++
Проще будет железа докупить и еще нодов воткнуть. Потому как не факт, что на С++ вы сделаете лучше/быстрее уже готовых решений в виде баз данных. И уж тем более не факт, что вы это сделаете в какие-то приемлемые сроки. Как тут правильно заметили, на С++ можно конечно специализированный код написать, который будет быстрее работать, чем существующие БД. Даже в пример всякие linkedin и прочие фейсбуки приводят. Только там и людей намного больше над этим работают (а многие из этих людей, с солидным опытом разработки подобных систем).
MSSQL же не масштабируется. Какое там железо прикупать? У меня база за 12 лет. Часть запросов строят по ней. Но - редко.
А большая часть это дневные спекулянты, которым нужна свежая информация только за сегодняшний день. И - без задержек.
Запросы все крайне простые. По моему это очевидно что использование STL даст прирост в скорости в десятки раз.
Зачем же тут PHP? И в чем его преимущество перед C# что бы заставить меня его учить? Пока ASP.NET технология вроде нравится, правда знаком еще не долго -пару месяцев
Dmitry67 wrote:Кстати, Adobe Premiere Pro и Adode After Effects - таки написаны на C++, unmanaged code.
И без всякой смеси managed/unmanaged, которую так любит M$
редкий пример чистых C++ продуктов
За счет этого они работают только под 64bit (это не ограничение - After Effects вообще память начинается с 8Gb и до бесконечности )
Для графики ресурсов всегда мало - это как раз чистая вотчина С++
)