Здравствуйте, BlackEric, Вы писали:
BE>Может есть какие-то тесты и сравнения? Или методика как можно сравнить?
Обобщенные тесты бессмысленны. Нужно сравнивать конкретные запросы и лучше всего, приближенные к боевым.
Здравствуйте, Dym On, Вы писали:
DO>Здравствуйте, BlackEric, Вы писали:
BE>>Может есть какие-то тесты и сравнения? Или методика как можно сравнить? DO>Обобщенные тесты бессмысленны. Нужно сравнивать конкретные запросы и лучше всего, приближенные к боевым.
Для этого нужно портировать пол приложения. Не один месяц работы.
А нам нужно принять решение о переходе или наоборот отказаться.
Здравствуйте, BlackEric, Вы писали:
BE>Для этого нужно портировать пол приложения. Не один месяц работы. BE>А нам нужно принять решение о переходе или наоборот отказаться. В этом случае проводить тесты еще бессмысленнее, поскольку их подгонят под желаемое решение (а оно скорее всего уже есть).
PS В текущих условиях переход работающего приложения с ms sql -> postgresql обуславливается в первую и главную очередь не техническими потребностями и характеристиками.
Здравствуйте, BlackEric, Вы писали:
BE>У кого-то уже был опыт перехода ms sql -> postgresql? BE>Как повлияло на скорость работы?
Я делал, поволияло незначительно. Но это в основном crud
BE>Может есть какие-то тесты и сравнения? Или методика как можно сравнить?
Я думаю тут хорошего ответа нет, ибо в конечном итоге ты замеришь скорость диска. Сравнивать надо на реальных запросах на реальных данных, сравнивать планы и время работы. Думаю в подавляющем большинстве случаев ms sql выиграет, но насколько выиграет зависит на 100% от запроса.
Здравствуйте, gandjustas, Вы писали:
G>Я делал, поволияло незначительно. Но это в основном crud
Меня CRUD тоже в основном интересует.
BE>>Может есть какие-то тесты и сравнения? Или методика как можно сравнить? G>Я думаю тут хорошего ответа нет, ибо в конечном итоге ты замеришь скорость диска. Сравнивать надо на реальных запросах на реальных данных, сравнивать планы и время работы. Думаю в подавляющем большинстве случаев ms sql выиграет, но насколько выиграет зависит на 100% от запроса.
Давно когда-то были тесты TPC (A, B, C, E кажется). Они еще актуальны? Их можно самому прогнать? Или где-то может есть сравнительные результаты?
Здравствуйте, BlackEric, Вы писали:
BE>Здравствуйте, gandjustas, Вы писали:
G>>Я делал, поволияло незначительно. Но это в основном crud BE>Меня CRUD тоже в основном интересует.
Скажем так: пользователь разницы не заметит.
BE>Давно когда-то были тесты TPC (A, B, C, E кажется). Они еще актуальны? Их можно самому прогнать? Или где-то может есть сравнительные результаты?
Нет, postgre в них не было, sql server давно не участвует.
BE>>>Может есть какие-то тесты и сравнения? Или методика как можно сравнить? G>>Я думаю тут хорошего ответа нет, ибо в конечном итоге ты замеришь скорость диска. Сравнивать надо на реальных запросах на реальных данных, сравнивать планы и время работы. Думаю в подавляющем большинстве случаев ms sql выиграет, но насколько выиграет зависит на 100% от запроса.
BE>Давно когда-то были тесты TPC (A, B, C, E кажется). Они еще актуальны? Их можно самому прогнать? Или где-то может есть сравнительные результаты?
если у тебя олтп нагрузка аля tpc-c почитай историю с уходом от postgres в Uber. постгрес не любит апдейты, где много индексов.
но глобально овердофига компаний пересело на постгрес и вполне с перфоменс приростом, т.к. сидели на блокировочном режиме, а на postgres получили нормальный версионный.
BE>>>>Может есть какие-то тесты и сравнения? Или методика как можно сравнить? G>>>Я думаю тут хорошего ответа нет, ибо в конечном итоге ты замеришь скорость диска. Сравнивать надо на реальных запросах на реальных данных, сравнивать планы и время работы. Думаю в подавляющем большинстве случаев ms sql выиграет, но насколько выиграет зависит на 100% от запроса.
BE>>Давно когда-то были тесты TPC (A, B, C, E кажется). Они еще актуальны? Их можно самому прогнать? Или где-то может есть сравнительные результаты?
Gt_>если у тебя олтп нагрузка аля tpc-c почитай историю с уходом от postgres в Uber. постгрес не любит апдейты, где много индексов. Gt_>но глобально овердофига компаний пересело на постгрес и вполне с перфоменс приростом, т.к. сидели на блокировочном режиме, а на postgres получили нормальный версионный.
Gt_>Gt_
Select во многих проектах на ms sql написаны с with(nolock), так что не знаю, даст ли тут версионник преимущество.
BE>>>>Может есть какие-то тесты и сравнения? Или методика как можно сравнить? G>>>Я думаю тут хорошего ответа нет, ибо в конечном итоге ты замеришь скорость диска. Сравнивать надо на реальных запросах на реальных данных, сравнивать планы и время работы. Думаю в подавляющем большинстве случаев ms sql выиграет, но насколько выиграет зависит на 100% от запроса.
BE>>Давно когда-то были тесты TPC (A, B, C, E кажется). Они еще актуальны? Их можно самому прогнать? Или где-то может есть сравнительные результаты?
Gt_>если у тебя олтп нагрузка аля tpc-c почитай историю с уходом от postgres в Uber. постгрес не любит апдейты, где много индексов. Gt_>но глобально овердофига компаний пересело на постгрес и вполне с перфоменс приростом, т.к. сидели на блокировочном режиме, а на postgres получили нормальный версионный.
Gt_>Gt_
В Uber это было давно и неправда. Они ушли с версии что-то типа 9.2, многих из тех проблем из-за которых они ушли уже нет.
Write amplification про который они говорят, это все еще реальная проблема но повлияет это на вас или нет зависит от вашей схемы и насколько интенсивна у вас запись по отношению к чтению.
VC>В Uber это было давно и неправда. Они ушли с версии что-то типа 9.2, многих из тех проблем из-за которых они ушли уже нет. VC>Write amplification про который они говорят, это все еще реальная проблема но повлияет это на вас или нет зависит от вашей схемы и насколько интенсивна у вас запись по отношению к чтению.
у нас нет постгрес, точно не повлияет :-D
какое-то время постгрес пилил zheap сторидж, там должен был быть нормальный undo как у оракла или mysql. zheap исправил бы положение, но последние пару лет новостей нет, видать забросили.
В этом случае проводить тесты еще бессмысленнее, поскольку их подгонят под желаемое решение (а оно скорее всего уже есть). 
