1.16, Аноним (-), 12:21, 05/09/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>можно выполнять только простейшие запросы SELECT с выборкой по определённому условию, но без поддержки сортировки и группировки
Если так использовать любую нормальную реляционную базу данных, то она запросто сможет "обрабатывать тысячи запросов в секунду".
| |
|
2.17, VoDA (ok), 12:26, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
>>можно выполнять только простейшие запросы SELECT с выборкой по определённому условию, но без поддержки сортировки и группировки
> Если так использовать любую нормальную реляционную базу данных, то она запросто сможет
> "обрабатывать тысячи запросов в секунду".
А репликацию и автоматическое восстановление после сбоев вы как сделаете?
PS не считая того, что Cassandra - multi-master, чем далеко не все РСУБД могут похвастаться.
| |
|
3.18, Аноним (-), 12:36, 05/09/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
>А репликацию и автоматическое восстановление после сбоев вы как сделаете?
В нормальных промышленных реляционках уже давно сделано.
| |
|
|
|
6.27, Фтщтнь (?), 14:43, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Oracle
> Из бесплатного Postgress
В Postgres нету встроенного multi-master-а, только stream master-slave. Все остальное реализуется PG-комьюнити и работает далеко не всегда гладко.
| |
|
|
8.35, Фтщтнь (?), 16:11, 05/09/2013 [^] [^^] [^^^] [ответить] | +2 +/– | Мы с вами прям как в анекдоте про ту ти ту ту Я грю Нет встроенной мастер-ма... текст свёрнут, показать | |
|
|
|
|
|
|
2.19, MVK (??), 12:45, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Если так использовать любую нормальную реляционную базу данных, то она запросто сможет
> "обрабатывать тысячи запросов в секунду".
- на массиве в 300 Тб?
| |
|
|
4.28, Фтщтнь (?), 14:45, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
> И что тут такого?
SELECT-ы из Postgres и MySQL при больших размерах БД это жопа, я вам скажу, так что как бы ничего, они просто тормозят.
| |
|
5.31, Аноним (-), 15:00, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
Postgres вполне активно ворочает сотни терабайт информации, на простых то запросах. Oracle тоже этим славен.
А к чему вы приплели MySQL вообще не понятно. Сия база данных никогда и не собиралась возится с большими объемами данных. Её вотчина - мелкие простые БД.
| |
|
6.33, Фтщтнь (?), 15:10, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Postgres вполне активно ворочает сотни терабайт информации, на простых то запросах. Oracle
> тоже этим славен.
> А к чему вы приплели MySQL вообще не понятно. Сия база
> данных никогда и не собиралась возится с большими объемами данных. Её
> вотчина - мелкие простые БД.
Приплел потому что с точки зрения здравого смысла MySQL вроде как и не годится для чего-то более серьезного, чем сайты-визитки, но в реальности Activision (точнее их сетевое подразделение Daemonware) используют оную в качестве одной из своих подсистем вполне успешно, ну о Facebook я надеюсь вам не стоит говорить. Так что в теории вроде как "фу, брось каку", а на практике совсем-совсем по другому все выходит.
| |
|
7.40, agent_007 (ok), 10:17, 06/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
> на практике совсем-совсем по другому все выходит.
на практике так выходит по вполне очевидной причине: на заре проекта им занимались ниасиляторы. в любых проектах, которые изначально делали люди с головой, никакого mysql нет, и не может быть в принципе.
| |
|
|
5.32, Аноним (-), 15:01, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> И что тут такого?
> SELECT-ы из Postgres и MySQL при больших размерах БД это жопа, я
> вам скажу, так что как бы ничего, они просто тормозят.
Нууу, если Postgres попилить как Кассандру на кучу нод, то будет уже не жопа...
Правда, инструментов для этого этого нет. Но если если сделать формат данных аля Кассандра (простые столбцы, никакой поддержки целостности на уровне вторичных ключей и тому подобного), то делать не так уж и много.
Тогда возникает разумный вопрос - а не проще было просто инструментарий для готовой БД накрутить, чем весь этот огород на Java городить?
| |
5.37, Аноним (37), 18:12, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
> SELECT-ы из Postgres
Смотрим план запроса, разбираемся в причинах, оптимизируем запрос и/или строим недостающие индексы. Вообще изучаем матчасть в области повышения производительности реляционных БД и скорости выполнения отдельных запросов.
| |
|
6.38, Фтщтнь (?), 22:54, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> SELECT-ы из Postgres
> Смотрим план запроса, разбираемся в причинах, оптимизируем запрос и/или строим недостающие
> индексы. Вообще изучаем матчасть в области повышения производительности реляционных БД
> и скорости выполнения отдельных запросов.
Да, но зачем, если например в NOSQL это можно сделать без лишних телодвижений?
| |
|
|
|
|
|
1.21, MaMoHT (?), 12:54, 05/09/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А как они jemalloc в код на Java привернули???
Они отрубили GC Java oo_O ??
| |
|
2.29, Stax (ok), 14:46, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
В кассандре off-heap кэш, аллоцируемый через нативные вызовы malloc/free.
| |
2.30, ДяДя (?), 14:58, 05/09/2013 [^] [^^] [^^^] [ответить]
| +/– |
В Netty его тоже используют. GC только для кучи работает. Есть способы не размещать данные в куче.
| |
|
|