Сообщение Re[2]: Как лучше использовать РСУБД для данных с динамическо от 04.10.2018 9:45
Изменено 04.10.2018 9:45 vsb
Re[2]: Как лучше использовать РСУБД для данных с динамической струк
Здравствуйте, Sinclair, Вы писали:
S>Если нужна фильтрация — то забудьте про NoSQL, всех советчиков посылайте лесом: у вас каждая операция будет упираться в full scan. Он будет прекрасно работать на тестовых объёмах, а в продакшне ляжет, а вам будут рассказывать о том, как зато легко это можно победить, подняв 1024 реплики базы в клауде. Тут поможет только нормальное структурированное хранилище.
Почему? Postgres умеет строить индекс по конкретному выражению внутри JSON и применять его для фильтрации (возможно и для сортировки, не проверял). Другие коммерческие базы наверняка не хуже. Не просто так же ввели отдельный тип для JSON, XML, весь смысл в том, чтобы база умела смотреть внутрь. Я думал в этом направлении, то бишь изначально предполагаем, что первичного фильтра нам хватает (например по типу товара), а для дальнейшей фильтрации база может и просканировать все записи. Если это начинает вызывать проблемы (у нас тысячи моделей мониторов и пользователи часто ищут мониторы с конкретными диагоналями), добавляем индекс по нужному подвыражению.
S>Если нужна фильтрация — то забудьте про NoSQL, всех советчиков посылайте лесом: у вас каждая операция будет упираться в full scan. Он будет прекрасно работать на тестовых объёмах, а в продакшне ляжет, а вам будут рассказывать о том, как зато легко это можно победить, подняв 1024 реплики базы в клауде. Тут поможет только нормальное структурированное хранилище.
Почему? Postgres умеет строить индекс по конкретному выражению внутри JSON и применять его для фильтрации (возможно и для сортировки, не проверял). Другие коммерческие базы наверняка не хуже. Не просто так же ввели отдельный тип для JSON, XML, весь смысл в том, чтобы база умела смотреть внутрь. Я думал в этом направлении, то бишь изначально предполагаем, что первичного фильтра нам хватает (например по типу товара), а для дальнейшей фильтрации база может и просканировать все записи. Если это начинает вызывать проблемы (у нас тысячи моделей мониторов и пользователи часто ищут мониторы с конкретными диагоналями), добавляем индекс по нужному подвыражению.
Re[2]: Как лучше использовать РСУБД для данных с динамическо
Здравствуйте, Sinclair, Вы писали:
S>Если нужна фильтрация — то забудьте про NoSQL, всех советчиков посылайте лесом: у вас каждая операция будет упираться в full scan. Он будет прекрасно работать на тестовых объёмах, а в продакшне ляжет, а вам будут рассказывать о том, как зато легко это можно победить, подняв 1024 реплики базы в клауде. Тут поможет только нормальное структурированное хранилище.
Почему? Postgres умеет строить индекс по конкретному выражению внутри JSON и применять его для фильтрации (возможно и для сортировки, не проверял). Другие коммерческие базы наверняка не хуже. Не просто так же ввели отдельный тип для JSON, XML, весь смысл в том, чтобы база умела смотреть внутрь. Я думал в этом направлении, то бишь изначально предполагаем, что первичного фильтра нам хватает (например по типу товара), а для дальнейшей фильтрации база может и просканировать все отобранные записи. Если это начинает вызывать проблемы (у нас тысячи моделей мониторов и пользователи часто ищут мониторы с конкретными диагоналями), добавляем индекс по нужному подвыражению.
S>Если нужна фильтрация — то забудьте про NoSQL, всех советчиков посылайте лесом: у вас каждая операция будет упираться в full scan. Он будет прекрасно работать на тестовых объёмах, а в продакшне ляжет, а вам будут рассказывать о том, как зато легко это можно победить, подняв 1024 реплики базы в клауде. Тут поможет только нормальное структурированное хранилище.
Почему? Postgres умеет строить индекс по конкретному выражению внутри JSON и применять его для фильтрации (возможно и для сортировки, не проверял). Другие коммерческие базы наверняка не хуже. Не просто так же ввели отдельный тип для JSON, XML, весь смысл в том, чтобы база умела смотреть внутрь. Я думал в этом направлении, то бишь изначально предполагаем, что первичного фильтра нам хватает (например по типу товара), а для дальнейшей фильтрации база может и просканировать все отобранные записи. Если это начинает вызывать проблемы (у нас тысячи моделей мониторов и пользователи часто ищут мониторы с конкретными диагоналями), добавляем индекс по нужному подвыражению.