Сообщение Re[10]: почему большущие базы? от 01.10.2020 5:56
Изменено 01.10.2020 5:57 Gt_
Re[10]: почему большущие базы?
Здравствуйте, IT, Вы писали:
Gt_>>угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.
IT>И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся.
что бы не получить минусы из обоих миров. вы отключили констреинты, отказались от транзакций в пользу exchange partition, у клиента подозреваю и консистентно вычитать уже и не выйдет. но при этом вы остались с тяжелой прослойкой субд, слабо работает в параллель и зажаты в структарх хранения субд. ну и главное — цена. это же все EE лицензии жрет.
IT>По-твоему, субд — это только целостность и транзакционность?
ну да. ну еще может консистентная выборка.
IT>И какие альтернативы?
файлики, бигдата. в файлики parquet на hadoop кластер можно писать с гораздо большим уровнем параллелизма. там колончатая структура + упаковка. поверх этих файликов mpp engine, который файлики в виде почти реляционных табличек, внешние потребители в основной массе и не поймут, что там файлики а не субд.
вот только колхозить и костылись заметно приходится, но если речь об альтернативе — она есть. у нас вот хранилище на оракле заменено.
Gt_
Gt_>>угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.
IT>И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся.
что бы не получить минусы из обоих миров. вы отключили констреинты, отказались от транзакций в пользу exchange partition, у клиента подозреваю и консистентно вычитать уже и не выйдет. но при этом вы остались с тяжелой прослойкой субд, слабо работает в параллель и зажаты в структарх хранения субд. ну и главное — цена. это же все EE лицензии жрет.
IT>По-твоему, субд — это только целостность и транзакционность?
ну да. ну еще может консистентная выборка.
IT>И какие альтернативы?
файлики, бигдата. в файлики parquet на hadoop кластер можно писать с гораздо большим уровнем параллелизма. там колончатая структура + упаковка. поверх этих файликов mpp engine, который файлики в виде почти реляционных табличек, внешние потребители в основной массе и не поймут, что там файлики а не субд.
вот только колхозить и костылись заметно приходится, но если речь об альтернативе — она есть. у нас вот хранилище на оракле заменено.
Gt_
Re[10]: почему большущие базы?
Здравствуйте, IT, Вы писали:
Gt_>>угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.
IT>И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся.
что бы не получить минусы из обоих миров. вы отключили констреинты, отказались от транзакций в пользу exchange partition, у клиента подозреваю и консистентно вычитать уже и не выйдет. но при этом вы остались с тяжелой прослойкой субд, которая слабо работает в параллель и зажаты в структарх хранения субд. ну и главное — цена. это же все EE лицензии жрет.
IT>По-твоему, субд — это только целостность и транзакционность?
ну да. ну еще может консистентная выборка.
IT>И какие альтернативы?
файлики, бигдата. в файлики parquet на hadoop кластер можно писать с гораздо большим уровнем параллелизма. там колончатая структура + упаковка. поверх этих файликов mpp engine, который файлики в виде почти реляционных табличек, внешние потребители в основной массе и не поймут, что там файлики а не субд.
вот только колхозить и костылись заметно приходится, но если речь об альтернативе — она есть. у нас вот хранилище на оракле заменено.
Gt_
Gt_>>угу. т.е. на проверку целостность вовсе не субд обеспечивает, а алгоритмы.
IT>И субд и алгоритмы. Там где можно воспользоваться возможностями субд мы от этого вовсе не отказываемся.
что бы не получить минусы из обоих миров. вы отключили констреинты, отказались от транзакций в пользу exchange partition, у клиента подозреваю и консистентно вычитать уже и не выйдет. но при этом вы остались с тяжелой прослойкой субд, которая слабо работает в параллель и зажаты в структарх хранения субд. ну и главное — цена. это же все EE лицензии жрет.
IT>По-твоему, субд — это только целостность и транзакционность?
ну да. ну еще может консистентная выборка.
IT>И какие альтернативы?
файлики, бигдата. в файлики parquet на hadoop кластер можно писать с гораздо большим уровнем параллелизма. там колончатая структура + упаковка. поверх этих файликов mpp engine, который файлики в виде почти реляционных табличек, внешние потребители в основной массе и не поймут, что там файлики а не субд.
вот только колхозить и костылись заметно приходится, но если речь об альтернативе — она есть. у нас вот хранилище на оракле заменено.
Gt_