|
|
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
BlazkowiczТак что это вопрос к Penkov Vladimir, почему он считает SQL несовместимым с highload. потому что 200к сложений в секунду + 40GB данных в сутки SQL не потянули ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 18:04:37 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Penkov VladimirBlazkowiczТак что это вопрос к Penkov Vladimir, почему он считает SQL несовместимым с highload. потому что 200к сложений в секунду + 40GB данных в сутки SQL не потянули + от 100кк уникальных ключей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 18:05:51 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
потому что 200к сложений в секунду + 40GB данных в сутки SQL не потянули О каких сложениях идет речь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 20:06:30 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
А если запустить похожий бенчмарк но с выборкой какой нибудь сущности размазанной по нескольким таблицам и допустим документ из NoSQL? Документы (то есть блобы) можно напихать в традиционную СУБД. Можно при желании индексировать по отдельным полям в блобах (postgres hstore, oracle index-by tables). В оракле есть cluster - данные физически хранятся в prejoined виде, но логически выглядят как обычные таблички. По скорости NoSQL проиграет. Например, в MongoDb есть один глобальный лок на всю базу ( http://stackoverflow.com/questions/7506124/is-it-true-that-mongodb-has-one-global-read-write-lock). Также предлагаю сравнить документацию по бэкапу в Postgres: http://www.postgresql.org/docs/9.1/static/continuous-archiving.html и в MongoDb: http://www.mongodb.org/display/DOCS/Backups ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 20:31:32 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
- не совсем понял о чем дискуссия? очередное сравнение слона и кита? Когда говорят о производительности NoSQL речь идет о производительности на больших объемах данных, о таких объемах на которых применение РСУБД либо экономически не выгодно, либо технологически проблематично. Т. е. NoSQL - это нишевое решение, которое не конкурирует с РСУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 21:25:28 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪпотому что 200к сложений в секунду + 40GB данных в сутки SQL не потянули О каких сложениях идет речь? взять число по ключу, прибавить 1, записать обратно. если ключа нет - создать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 22:10:08 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪНапример, в MongoDb есть один глобальный лок на всю базу ( http://stackoverflow.com/questions/7506124/is-it-true-that-mongodb-has-one-global-read-write-lock). Также предлагаю сравнить документацию по бэкапу в Postgres: http://www.postgresql.org/docs/9.1/static/continuous-archiving.html и в MongoDb: http://www.mongodb.org/display/DOCS/Backups из всех noSQL решений вы выбрали худшее и сравнили с лидерами ))) сравните с hbase тогда уж ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 22:11:18 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Penkov Vladimirвзять число по ключу, прибавить 1, записать обратно. если ключа нет - создать. хитрый апдейт на 200 000 записей в секунду? а кроме этого в табличке какие еще поля? запись на диск или все таки только в память? на какой машине это все делалось? какая именно NoSQL? случайно не редис? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 22:57:14 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Это в один поток. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2012, 23:24:49 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
1024ТимоНпропущено... Складывается ощущение что вы ошибаетесь. Вы серьезно думаете что это просто дань моде? это не дань моде. Это очередные грабли. SQL слишком сложен для большинства, в результате модными стали простейшие структуры данных а вся мощь SQL отброшена. Типа десяток сджойненных таблиц в запросе который сам соптимизирует и выполнит мгновенно это хуже чем самому городить сбор данных по убогим наборам ключ-значение и пытаться добиться производительности над которой в Oracle работали десятки лет. плюсую, но это верно только для случая, когда sql может работать с террабайтами данных - а таких решений два, может три на всю планету ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 02:38:53 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. Это в один поток. я нифига в этом не понял, что тут происходит? суть наших изысканий. есть 1кк пользователей, по каждому много параметров (до 100, у нас избыточная запись для быстрого чтения потом). нужно при совершении некого события от пользователя посчитать это событие. событий - по 100-200к в сек. у нас hbase был, с таким объемом он слег. написали свою memory based БД, она вроде работает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 08:23:17 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Кореец на какой машине это все делалось? какая именно NoSQL? случайно не редис? там hbase в кластере ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 08:24:16 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
ShSergeЗа последний десяток лет, не написал ни одного селекта с меньше, чем тремя приджойненными таблицами. Исключая, ясен перец, справочник полов - Мужской(М), Женский(Ж), Неопределённый(Н). Кстати, последний иногда тоже имеет место быть. привильно писать "оно ещё не определилось " ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 08:37:22 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Добрый день, Blazkowicz! >> Кстати, NoSQL - отличный кэш для SQL. > Да, ну? А мы думали EhCache в Hibernate как-то по другому работает. Ну так можно рассматривать EhCache как NoSQL БД :) -- Алексей JID: alxt@ya.ru Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 08:49:10 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Penkov Vladimirя нифига в этом не понял, что тут происходит? он 2 миллиона раз увеличил sequence на 1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 11:56:43 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
chpashaPenkov Vladimirя нифига в этом не понял, что тут происходит? он 2 миллиона раз увеличил sequence на 1 а sequence всего 1? нужно много их ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 12:55:23 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
Penkov Vladimirchpashaпропущено... он 2 миллиона раз увеличил sequence на 1 а sequence всего 1? нужно много их х.з. что хотел сказать автор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 14:26:46 |
|
||
|
JPA vs JDBC для высоконагруженного приложения.
|
|||
|---|---|---|---|
|
#18+
а sequence всего 1? нужно много их Создайте много сиквенсов, по одному на каждого пользователя. х.з. что хотел сказать автор Я хотел сказать, что для такой задачи надо использовать сиквенсы, а не столбцы таблиц. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.07.2012, 16:20:32 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=37863822&tid=2131428]: |
0ms |
get settings: |
15ms |
get forum list: |
30ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
57ms |
get topic data: |
22ms |
get forum data: |
4ms |
get page messages: |
111ms |
get tp. blocked users: |
2ms |
| others: | 352ms |
| total: | 607ms |

| 0 / 0 |
