|
|
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
мы получаем данные из чёрного ящика по апи, в котором они приезжают именно в таком виде. Но никто не обязывает вас хранить данные именно в этом виде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2015, 23:19:52 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
Barvinok, короче, главная проблема - отсутствие компетенции в проектировании баз данных и создании приложений для них. и MySQL тут точно мимо. не потянет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2015, 23:27:42 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
можно рассчитывать на то, что работа с индексами бинарных блобов как-то лучше, чем у строк? -- нет, нельзя. -- ох. но ведь ищут игроков и локации по гуиду, который не мы задаём, а он является внутриигровым, заложенным в архитектуру игры не нами. то есть придётся сначала лезть в таблицу гуидов игроков, искать там ид, учитывая возможные переименования, потом то же самое для локаций а потом только основной запрос. опять же, ощущение оверкилла ради экономии места под хранение данных, которое (место) не является проблемой. -- проблемой является не только место само по себе, но и скорости обработки таких объемов данных. объемы немаленькие, а чем больше объем, тем дольше и сложнее он обрабатывается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2015, 23:36:28 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
Barvinokmiksoftпропущено... BINARY(16) - это не блоб, это та же строка, только которая не подвергается преобразованиям кодировок. Т.е., грубо говоря, это CHAR без кодировки. ну почему же это строка? вот типичный вид гуида из игры, как он приезжает через апи: Код: plaintext теперь вы предлагаете хранить её как BINARY(16), т.е. это уже строкой перестаёт быть и становится бинарным фрагментом что-ли. да, это займёт меньше места, но точно ли поиск по бинарным данным лучше чем по строке? поиск не будет быстрее, но быстрее будет все чтения, потому, что размер данных будет в два раза меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2015, 23:40:00 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
MasterZivпроблемой является не только место само по себе, но и скорости обработки таких объемов данных. объемы немаленькие, а чем больше объем, тем дольше и сложнее он обрабатывается. Это не традиционное приложение, а просто хранилище логов. Все отлично будет с mysql и myisam. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2015, 00:44:25 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
netwindMasterZivпроблемой является не только место само по себе, но и скорости обработки таких объемов данных. объемы немаленькие, а чем больше объем, тем дольше и сложнее он обрабатывается. Это не традиционное приложение, а просто хранилище логов. Все отлично будет с mysql и myisam. пофигу, что это за приложение. а про какую-то там аналитику ТС и сам говорил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2015, 11:44:32 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
MasterZivnetwindпропущено... Это не традиционное приложение, а просто хранилище логов. Все отлично будет с mysql и myisam. пофигу, что это за приложение. а про какую-то там аналитику ТС и сам говорил. не дописал.... такие объемы данных с индексом и загрузить уже будет трудно, а без индексов - бесполезно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2015, 11:46:04 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
MasterZiv, переусложняете. Я просто знаю какое применение у этой базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2015, 13:22:32 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
netwindMasterZiv, переусложняете. Я просто знаю какое применение у этой базы. внезапно O_O ладно, чего уж там прятаться... вот так она выглядит после (я надеюсь) нормализации, в полном виде: Код: sql 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. 27. постарался учесть все ваши замечания, только вынес отображение гуида на иды в три отдельные таблицы, а не одну. теперь такие вопросы: 1) написал скрипт разбора старого лога в новую схему таблицы, обработал пробный миллион событий и смотрю - размер 137.2 MiB, индексы 77.2 MiB. Это нормально? ну, то есть, я конечно рад, что таблица будет занимать 56 GiB вместо 145 GiB, но какой же тогда будет индекс? :( 2) далее, отображения сделаны так, например, для игроков Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. это для того, чтобы отслеживать переименования, т.е. уникальность есть у разных имён с тем же гуидом. но тут проблема - я не знаю, как правильно написать INSERT ODKU, чтобы при срабатывании по дубликату можно было получить id, под которым этот дубликат там уже был ранее записан (ничего в самой таблице не меняя). сейчас я просто пишу отдельный SELECT, но это как-то криво и медленно. подскажите, пожалуйста. 3) наконец, с ростом новой таблицы падает скорость заполнения. мы только перешагнули за миллион, а уже на глаз притормаживает раза в полтора-два. есть какие-то стандартные способы борьбы с этим? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2015, 02:40:39 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
я так и не понял зачем вообще хранить основной guid события ? он же не нужен. Нужен порядковый номер и прочие атрибуты. автор3) наконец, с ростом новой таблицы падает скорость заполнения. мы только перешагнули за миллион, а уже на глаз притормаживает раза в полтора-два. есть какие-то стандартные способы борьбы с этим стандартные все те же - денормализация из "запрещенных" можно попробовать DELAY_KEY_WRITE = 1; и файловую систему без журнала смонтировать. Если вы арендуете сервер (а где вы вообще нашли физиеский сервер на 2гб) на нормальной площадке, там же никто не перезагружает его внезапно. Транзакции и надежная фиксация данных на диск не нужна.. Опять же, исходя из того как я представляю себе ценность данной информации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2015, 03:38:27 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
чёрт возьми, случайно отправил незаконченное сообщение. а функции редактирования на этом форуме нет? :( netwindя так и не понял зачем вообще хранить основной guid события ? он же не нужен. Нужен порядковый номер и прочие атрибуты. так и будет потом, когда мы пересоберём тот старый евентлог. дело в том, что при экспериментах с ним была залита часть событий дублирующих уже существующие, поэтому нужно будет отфильтровать их обязательно. автор3) наконец, с ростом новой таблицы падает скорость заполнения. мы только перешагнули за миллион, а уже на глаз притормаживает раза в полтора-два. есть какие-то стандартные способы борьбы с этим стандартные все те же - денормализация из "запрещенных" можно попробовать DELAY_KEY_WRITE = 1; и файловую систему без журнала смонтировать. Если вы арендуете сервер (а где вы вообще нашли физиеский сервер на 2гб) на нормальной площадке, там же никто не перезагружает его внезапно. сервер физический у меня на кухне стоит. п.3. вопроса я снимаю, с ODKU вроде бы разобрался сам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2015, 03:52:13 |
|
||
|
Большая таблица (масштабируемость?)
|
|||
|---|---|---|---|
|
#18+
Barvinok, я бы не стал делать в таком случае DELAY_KEY_WRITE. Не очень надежно и myisam чинить потом долго. Проц очень уж слабый для LGA775. Там были намного лучше варианты. Это как раз влияет на создание индексов и починку таблиц. Но вы можете временные сервисные действия на хорошем ПК c SSD выполнять, а постоянно эксплуатировать "на кухне". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2015, 17:20:05 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=39137704&tid=1832332]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
182ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 469ms |

| 0 / 0 |
