O
Не дивилися на схожі проекти? Можливо є сенс їх проаналізувати і для початку взяти їх напрацювання?
Size: a a a
2017 September 08
VD
ID:162835499
структура данных будет динамическая, т.к. сказать точно какая в ней информаци будет храниться можно только в начале... это будут правила поведения для бота, а далее бот будет сам наполнять ее данными и изменять структуру. т.е. по сути это будет база знаний.
Мне кажется, в таком случае лучше использовать что-то вроде документных или "графовых" (не уверен точно в названии) баз данных
VD
Посмотри в сторону MongoDB
A
Монга с таким объемом не справится.
VD
Шардинг и репликация и все заведётся аххахахаха
R
Хакеры атаковали 26000 пользователей MongoDB - SecureNews
https://securenews.ru/mongodb/
https://securenews.ru/mongodb/
A
Шардинг и репликация и все заведётся аххахахаха
И будут потом простейшие запросы воплнятся за 1-2 минуты.
A
А если туда еще будет что-то параллельно писаться, то ответ от базы можно будет ждать вечно
A
Монга в данном случае подойдет лишь для того, чтоб единожды записать туда те "скажем 5 Тб" и потом их успешно вместе с монгой удалить.
RG
А отношения между данными удобно представить графом? В таком случае можно использовать что-то вроде Neo4j.
A
neo4j тоже становится очень задумчива с большим количеством данных.
A
Если достаточно много связей, то на 1 инстансе тупняки начинаются на объеме порядка пары Гб данных (~500к доков)
RG
Все базы так :) Без индексов и грамотного распределения нагрузки. Разве что im-memory key-value store всегда быстрый
RG
Mongo на самом деле не плохое решение, но оптимизируется index-ами и sharding-key. Размер каждого документа ограничен 16 mb насколько я помню. Поэтому если документы до 16 мб и есть удачный sharding-key то можно применить. Иначе будет долго
RG
Про манеру доступа к данным так и не ответили. Так же неясна структура атомарных единиц тоже.
И всё таки интересно почему не подходят файлы на диске.
И всё таки интересно почему не подходят файлы на диске.
TS
Файловая система тоже база данных, у которой путь - первичный ключ, а папка - это kay-value хранилище, которое работает чаще лучше БД ))))
Y@
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
АК
кто то начал учить Python?