Дано — прототип объектной main memory базы данных, умеющей транзакции(ACID) и выполнять запросы (пока что только простые). Эта штука рассчитана на очень интенсивную работу с данными (чтение одного объекта в режиме случайного доступа — меньше одной микросекунды, несколько тысяч транзакций в сек. на одной машине) при относительно небольших объемах данных — сотни мегабайт/несколько гигабайт. Теперь собственно вопрос — где это можно использовать если довести до ума?
30.08.11 16:37: Перенесено модератором из 'Shareware и бизнес' — retalik
Здравствуйте, Аноним, Вы писали:
А>Дано — прототип объектной main memory базы данных, умеющей транзакции(ACID) и выполнять запросы (пока что только простые). Эта штука рассчитана на очень интенсивную работу с данными (чтение одного объекта в режиме случайного доступа — меньше одной микросекунды, несколько тысяч транзакций в сек. на одной машине) при относительно небольших объемах данных — сотни мегабайт/несколько гигабайт. Теперь собственно вопрос — где это можно использовать если довести до ума?
Здравствуйте, UA, Вы писали:
UA>Здравствуйте, Аноним, Вы писали:
А>>Дано — прототип объектной main memory базы данных, умеющей транзакции(ACID) и выполнять запросы (пока что только простые). Эта штука рассчитана на очень интенсивную работу с данными (чтение одного объекта в режиме случайного доступа — меньше одной микросекунды, несколько тысяч транзакций в сек. на одной машине) при относительно небольших объемах данных — сотни мегабайт/несколько гигабайт. Теперь собственно вопрос — где это можно использовать если довести до ума?
UA>ORM?
Здравствуйте, Аноним, Вы писали:
А>Дано — прототип объектной main memory базы данных, умеющей транзакции(ACID) и выполнять запросы (пока что только простые). Эта штука рассчитана на очень интенсивную работу с данными (чтение одного объекта в режиме случайного доступа — меньше одной микросекунды, несколько тысяч транзакций в сек. на одной машине) при относительно небольших объемах данных — сотни мегабайт/несколько гигабайт. Теперь собственно вопрос — где это можно использовать если довести до ума?
Здравствуйте, Аноним, Вы писали:
А>Дано — прототип объектной main memory базы данных, умеющей транзакции(ACID) и выполнять запросы (пока что только простые). Эта штука рассчитана на очень интенсивную работу с данными (чтение одного объекта в режиме случайного доступа — меньше одной микросекунды, несколько тысяч транзакций в сек. на одной машине) при относительно небольших объемах данных — сотни мегабайт/несколько гигабайт. Теперь собственно вопрос — где это можно использовать если довести до ума?
Народ на сходных решениях как-то начитнает стартапы и, похоже, зарабатывает деньги. Например — rethink DB.
Здравствуйте, A13x, Вы писали:
A>Здравствуйте, Аноним, Вы писали:
А>>Дано — прототип объектной main memory базы данных, умеющей транзакции(ACID) и выполнять запросы (пока что только простые). Эта штука рассчитана на очень интенсивную работу с данными (чтение одного объекта в режиме случайного доступа — меньше одной микросекунды, несколько тысяч транзакций в сек. на одной машине) при относительно небольших объемах данных — сотни мегабайт/несколько гигабайт. Теперь собственно вопрос — где это можно использовать если довести до ума?
A>Народ на сходных решениях как-то начитнает стартапы и, похоже, зарабатывает деньги. Например — rethink DB.
Все это настолько узкоспециализированно и не надежно (in memory DB), что можно расчитывать на годы работы и пару залетных клиентов, не более.
Здравствуйте, AnonThisTime, Вы писали:
ATT>Все это настолько узкоспециализированно и не надежно (in memory DB), что можно расчитывать на годы работы и пару залетных клиентов, не более.
Расскажи это SAP-овцам, они наверное зря HANNA сделали
За main memory db будущее, так как память становится все дешевле. Фишка этой технологии в том, что она позволяет анализировать данные на порядок быстрее, что позволяет например считать бизнес аналитику в мягком реальном времени. Мой проект, это pet project, его слабая сторона в том, что вся база целиком должна помещаться в память. Алгоритмы, которые я использую не позволяют делать partitioning, так как изначально это планировалось для несколько специфичного использования. Вот я и интересуюсь, стоит ли пытаться это развивать дальше
Здравствуйте, BubbleWrap, Вы писали:
BW>Здравствуйте, AnonThisTime, Вы писали:
ATT>>Все это настолько узкоспециализированно и не надежно (in memory DB), что можно расчитывать на годы работы и пару залетных клиентов, не более.
BW>Расскажи это SAP-овцам, они наверное зря HANNA сделали BW>За main memory db будущее, так как память становится все дешевле. Фишка этой технологии в том, что она позволяет анализировать данные на порядок быстрее, что позволяет например считать бизнес аналитику в мягком реальном времени. Мой проект, это pet project, его слабая сторона в том, что вся база целиком должна помещаться в память. Алгоритмы, которые я использую не позволяют делать partitioning, так как изначально это планировалось для несколько специфичного использования. Вот я и интересуюсь, стоит ли пытаться это развивать дальше
Я не буду тебя убеждать, что небо не всегда голубое и что "За main memory db будущее" может лелеять только тебя. Я смотрю на это со своей колокольни: за 10 лет разношерстных проектов с базами в сотни гиг мне никогда не приходила мысль перенести хоть часть данных в память ибо это не надежно (и владелец проекта яйки поотрывает если что); это имеет ограничения по размеру; это не обкатано (пионеры тут врятли найдутся); преимущества смутны. Если нужен быстрый доступ в данным, in mem БД вспомнится в последний момент, да и не нужна тут БД, софтового кеша достаточно для расчетов уровня не Уол-Стрит. Т.е. только САПовцы и остаются, вот к ним вам и дорога за советом, имхо.
Здравствуйте, BubbleWrap, Вы писали:
BW>Здравствуйте, AnonThisTime, Вы писали:
ATT>>Все это настолько узкоспециализированно и не надежно (in memory DB), что можно расчитывать на годы работы и пару залетных клиентов, не более.
BW>Расскажи это SAP-овцам, они наверное зря HANNA сделали BW>За main memory db будущее, так как память становится все дешевле. Фишка этой технологии в том, что она позволяет анализировать данные на порядок быстрее, что позволяет например считать бизнес аналитику в мягком реальном времени. Мой проект, это pet project, его слабая сторона в том, что вся база целиком должна помещаться в память. Алгоритмы, которые я использую не позволяют делать partitioning, так как изначально это планировалось для несколько специфичного использования. Вот я и интересуюсь, стоит ли пытаться это развивать дальше
Проблема только в том что неравенство DB SIZE > HDD SIZE > RAM SIZE остается неизменным. И когда будет RAM по 3 террабайта? — думаю что не скоро, но даже если и будет то базы будут на порядок большими.
Здравствуйте, AnonThisTime, Вы писали:
ATT>Я не буду тебя убеждать, что небо не всегда голубое и что "За main memory db будущее" может лелеять только тебя. Я смотрю на это со своей колокольни: за 10 лет разношерстных проектов с базами в сотни гиг мне никогда не приходила мысль перенести хоть часть данных в память ибо это не надежно (и владелец проекта яйки поотрывает если что); это имеет ограничения по размеру; это не обкатано (пионеры тут врятли найдутся); преимущества смутны. Если нужен быстрый доступ в данным, in mem БД вспомнится в последний момент, да и не нужна тут БД, софтового кеша достаточно для расчетов уровня не Уол-Стрит. Т.е. только САПовцы и остаются, вот к ним вам и дорога за советом, имхо.
почему ненадежно? данные ведь не только в памяти хранятся, они записываются на диск и реплицируются на множество машин. я еще не делал репликацию, но тем не менее могу сказать что main memory db может быть очень надежна.
Кэш работает хуже, во первых потому что кэшируются не все данные(у меня все данные в памяти), еще нужна поддержка целостности этого кэша, во вторых потому, что дизайн РБД не позволяет работать быстро. Все структуры данных, которые используют РБД для хранения данных оптимизированы для быстрой работы с диском, не с памятью. Поэтому, РБД + кэширование всех данных это все равно на порядок медленнее чем main memory db. Моя система отличается от других тем, что она хранит данные максимально близко к приложению использующему эти данные, данные не передаются по сети и даже IPC не используется при чтении. Никакой кэш так не умеет.
Здравствуйте, UA, Вы писали:
UA>Здравствуйте, BubbleWrap, Вы писали:
BW>>Здравствуйте, AnonThisTime, Вы писали:
ATT>>>Все это настолько узкоспециализированно и не надежно (in memory DB), что можно расчитывать на годы работы и пару залетных клиентов, не более.
BW>>Расскажи это SAP-овцам, они наверное зря HANNA сделали BW>>За main memory db будущее, так как память становится все дешевле. Фишка этой технологии в том, что она позволяет анализировать данные на порядок быстрее, что позволяет например считать бизнес аналитику в мягком реальном времени. Мой проект, это pet project, его слабая сторона в том, что вся база целиком должна помещаться в память. Алгоритмы, которые я использую не позволяют делать partitioning, так как изначально это планировалось для несколько специфичного использования. Вот я и интересуюсь, стоит ли пытаться это развивать дальше
UA>Проблема только в том что неравенство DB SIZE > HDD SIZE > RAM SIZE остается неизменным. И когда будет RAM по 3 террабайта? — думаю что не скоро, но даже если и будет то базы будут на порядок большими.
Ну это явно не мой случай, мой случай — у нас мало данных — несколько гигабайт, но с ними нужно работать очень интенсивно. Скажем, приложения, которые занимаются какими нибудь вычислениями на основе какой нибудь модели, которая вот именно такого размера — сотни/тысячи/десятки_тысяч мегабайт. В этом случае можно будет не заниматься созданием структур данных в памяти, хранящих всю модель а использовать мою недо-БД
Здравствуйте, UA, Вы писали:
UA>Проблема только в том что неравенство DB SIZE > HDD SIZE > RAM SIZE остается неизменным. И когда будет RAM по 3 террабайта? — думаю что не скоро, но даже если и будет то базы будут на порядок большими.
3Тб оперативы — фигня. Модули на 8Гб стоят при покупке в больших количествах меньше $100, так что 3Тб оперативы будет стоить порядка $30000. Ещё примерно столько же на аппаратную платформу с достаточным количеством слотов для расширения.
Это примерно столько же, сколько стоит пара лицензий на Oracle RAC. При производительности на порядки выше.
Здравствуйте, BubbleWrap, Вы писали:
BW>Здравствуйте, AnonThisTime, Вы писали:
ATT>>Я не буду тебя убеждать, что небо не всегда голубое и что "За main memory db будущее" может лелеять только тебя. Я смотрю на это со своей колокольни: за 10 лет разношерстных проектов с базами в сотни гиг мне никогда не приходила мысль перенести хоть часть данных в память ибо это не надежно (и владелец проекта яйки поотрывает если что); это имеет ограничения по размеру; это не обкатано (пионеры тут врятли найдутся); преимущества смутны. Если нужен быстрый доступ в данным, in mem БД вспомнится в последний момент, да и не нужна тут БД, софтового кеша достаточно для расчетов уровня не Уол-Стрит. Т.е. только САПовцы и остаются, вот к ним вам и дорога за советом, имхо.
BW>почему ненадежно? данные ведь не только в памяти хранятся, они записываются на диск и реплицируются на множество машин. я еще не делал репликацию, но тем не менее могу сказать что main memory db может быть очень надежна.
вы реально не видите разницу надержности винта (а уж про РЕЙД я вообще молчу) и данных в памяти? Если в ДЦ ударит молния, то в вашем случае клиент восстановит данные за не позднее, чем была размер паузы между бекапами (часто системы делают бекапа чаще 1 раз в день?). В случае НДД, человек просто подымет инстанс ОС и проверит данные на целостность, без потери оперативных данных.
BW>Кэш работает хуже, во первых потому что кэшируются не все данные(у меня все данные в памяти), еще нужна поддержка целостности этого кэша, во вторых потому, что дизайн РБД не позволяет работать быстро. Все структуры данных, которые используют РБД для хранения данных оптимизированы для быстрой работы с диском, не с памятью. Поэтому, РБД + кэширование всех данных это все равно на порядок медленнее чем main memory db. Моя система отличается от других тем, что она хранит данные максимально близко к приложению использующему эти данные, данные не передаются по сети и даже IPC не используется при чтении. Никакой кэш так не умеет.
по выделенному:
1) вы пытаетесь себя убедить, что ваш продукт лучше, не более. Тут спорить бессмысленно. В кеш можно запихнуть ровно столько, сколько надо, а не "не все данные". Мало памяти для этого? ну тогда и вам там не развернуться.
2) целостность там поддерживать ибо логика работы кеша элементарна — thread-safe список объектов. Ну плюс возможно "индексы" можно прикрутить для быстрого поиска.
3) раз уж вы перескочили с кеша на БД, то РДБ на то и Р, что она массштабируется. Т.е. утверждение "не позволяет работать быстро" не верно. Обычная БД да, при возростании нагрузки будет ухудшать показатели. Но тогда нужна РДБ, всего то.
4) совершенно верно, НО у многих нормальных СУБД есть отдельный кеш в памяти. Отдай ей десяток гиг и будет гибрид из файловой БД и in-memory, который по надежности обскачет вас легко. И, самое главное, теперешние СУБД уже предоставляют возможность кеширования в памяти из коробки!
5) да не нужны все данные в памяти 99% систем. Там, где нужно делать реалтайм расчеты — возможно, я и сказал, что это ваш потенциальный рынок. В остальных случаях файловой БД+кеша часто используемых данных/запросов — с головой хватит. А при правильной инфраструктуре (raid на sdd дисках) так и вообще не заставит владельца думать о другоих вариантах. Никто не спорит, что скорости вашего варианта и файлового будут отличаться, но преимущества здесь только для узкоспециализированных задач.
6) "данные не передаются по сети и даже IPC не используется при чтении" — а вот с этого нужно и было начинать. Теперь ваше поле деятельности еще более сужается. Обычно субд с средних/больших системах работают как отдельный, как минимум, процесс и как максимум — хост(ы) (компьютер). Embedded БД (SQLite, etc.) юзаются когда нужно что-то мелкое локально хранить без разворота субд. Как вы сюда втиснетесь я даж не знаю... все сказанное — имхо.
Здравствуйте, BubbleWrap, Вы писали:
BW>Ну это явно не мой случай, мой случай — у нас мало данных — несколько гигабайт, но с ними нужно работать очень интенсивно. Скажем, приложения, которые занимаются какими нибудь вычислениями на основе какой нибудь модели, которая вот именно такого размера — сотни/тысячи/десятки_тысяч мегабайт. В этом случае можно будет не заниматься созданием структур данных в памяти, хранящих всю модель а использовать мою недо-БД
Ты действительно считаешь, что БД общего назначения будет эффективнее специально заточенных структур данных? Особенно для случая, когда, цитирую, "...с ними нужно работать очень интенсивно..."?
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, UA, Вы писали:
UA>>Проблема только в том что неравенство DB SIZE > HDD SIZE > RAM SIZE остается неизменным. И когда будет RAM по 3 террабайта? — думаю что не скоро, но даже если и будет то базы будут на порядок большими. C>3Тб оперативы — фигня. Модули на 8Гб стоят при покупке в больших количествах меньше $100, так что 3Тб оперативы будет стоить порядка $30000. Ещё примерно столько же на аппаратную платформу с достаточным количеством слотов для расширения.
С ораклом можна получить предсказуемый результат с предсказуемыми рисками. А c memory db вообще не понятки как она будет себя вести когда отключится питание, будет битая память, будут утечки памяти в этой дб, как делать зеркало для этой дб, кластер, бэкап без остановки дб, доступ к этой дб из сети. Да и разработка под такую дб будет стоить дороже.
Здравствуйте, UA, Вы писали:
C>>3Тб оперативы — фигня. Модули на 8Гб стоят при покупке в больших количествах меньше $100, так что 3Тб оперативы будет стоить порядка $30000. Ещё примерно столько же на аппаратную платформу с достаточным количеством слотов для расширения. UA>С ораклом можна получить предсказуемый результат с предсказуемыми рисками.
ROTFL.
UA>А c memory db вообще не понятки как она будет себя вести когда отключится питание, будет битая память, будут утечки памяти в этой дб, как делать зеркало для этой дб, кластер, бэкап без остановки дб, доступ к этой дб из сети. Да и разработка под такую дб будет стоить дороже.
Как раз вряд ли. Решений для in-memory DB уже полно. А вот с Ораклом всё плохо — аналогичный по производительности кластер, скорее всего, будет стоить примерно на порядок дороже.
Здравствуйте, Cyberax, Вы писали:
C>3Тб оперативы — фигня. Модули на 8Гб стоят при покупке в больших количествах меньше $100, так что 3Тб оперативы будет стоить порядка $30000. Ещё примерно столько же на аппаратную платформу с достаточным количеством слотов для расширения.
Хм-м. А нам админы на планки в 32Гб для сервера год назад безумные цифры называли. Плюс добавок кол-во слотов ограничено — т.е. в одном адресном пространстве получить 3Тб будет дороже $30000. А в разных адресных пространствах — это не интересно.
C>Это примерно столько же, сколько стоит пара лицензий на Oracle RAC. При производительности на порядки выше.
Здравствуйте, Cyberax, Вы писали: UA>>С ораклом можна получить предсказуемый результат с предсказуемыми рисками. C>ROTFL.
UA>>А c memory db вообще не понятки как она будет себя вести когда отключится питание, будет битая память, будут утечки памяти в этой дб, как делать зеркало для этой дб, кластер, бэкап без остановки дб, доступ к этой дб из сети. Да и разработка под такую дб будет стоить дороже. C>Как раз вряд ли. Решений для in-memory DB уже полно. А вот с Ораклом всё плохо — аналогичный по производительности кластер, скорее всего, будет стоить примерно на порядок дороже.
Кстати в Оракле это понимают. Потому и прикупили TimesTen
Здравствуйте, Andrei N.Sobchuck, Вы писали:
C>>3Тб оперативы — фигня. Модули на 8Гб стоят при покупке в больших количествах меньше $100, так что 3Тб оперативы будет стоить порядка $30000. Ещё примерно столько же на аппаратную платформу с достаточным количеством слотов для расширения. ANS>Хм-м. А нам админы на планки в 32Гб для сервера год назад безумные цифры называли.
Мы планки в 16Гб за $350 покупали.
ANS>Плюс добавок кол-во слотов ограничено — т.е. в одном адресном пространстве получить 3Тб будет дороже $30000. А в разных адресных пространствах — это не интересно.
Специальная железка нужна, конечно же. Производители NAS их часто продают.
Здравствуйте, AnonThisTime, Вы писали:
ATT>по выделенному: ATT>1) вы пытаетесь себя убедить, что ваш продукт лучше, не более. Тут спорить бессмысленно. В кеш можно запихнуть ровно столько, сколько надо, а не "не все данные". Мало памяти для этого? ну тогда и вам там не развернуться.
я не пытаюсь, я не знаю и само собой я понимаю, что мой "продукт" — нишевый
ATT>2) целостность там поддерживать ибо логика работы кеша элементарна — thread-safe список объектов. Ну плюс возможно "индексы" можно прикрутить для быстрого поиска.
кэш не может сравниться с in memory db вот почему — допустим у нас есть данные, которые всем очень нужны и к ним часто обращаются, теперь представим, что один из клиентов их изменяет. в случае кэша произойдет инвалидация старых данных и при следующем чтении они не будут в кэше, в случае in memory db — будут. для некоторых приложений это может быть критично (вот только для каких — хз)
ATT>3) раз уж вы перескочили с кеша на БД, то РДБ на то и Р, что она массштабируется. Т.е. утверждение "не позволяет работать быстро" не верно. Обычная БД да, при возростании нагрузки будет ухудшать показатели. Но тогда нужна РДБ, всего то.
я вообще имел ввиду реляционные БД, но если речь зашла о распределенных БД, то там тоже не все так просто как кажется. такие системы масштабируются в ширину, путем добавления новых серверов на которые реплицируются данные и которые берут на себя часть нагрузки. Это увеличивает пропускную способность, но не увеличивает латентность(а скорее даже наоборот .
ATT>4) совершенно верно, НО у многих нормальных СУБД есть отдельный кеш в памяти. Отдай ей десяток гиг и будет гибрид из файловой БД и in-memory, который по надежности обскачет вас легко. И, самое главное, теперешние СУБД уже предоставляют возможность кеширования в памяти из коробки!
конечно предоставляют, но за этими кэшированными данными опять же нужно ходить на сервер
ATT>5) да не нужны все данные в памяти 99% систем. Там, где нужно делать реалтайм расчеты — возможно, я и сказал, что это ваш потенциальный рынок. В остальных случаях файловой БД+кеша часто используемых данных/запросов — с головой хватит. А при правильной инфраструктуре (raid на sdd дисках) так и вообще не заставит владельца думать о другоих вариантах. Никто не спорит, что скорости вашего варианта и файлового будут отличаться, но преимущества здесь только для узкоспециализированных задач.
ну так о том и речь, случай — узкий. как делать partitioning я еще не придумал и вряд-ли придумаю
ATT>6) "данные не передаются по сети и даже IPC не используется при чтении" — а вот с этого нужно и было начинать. Теперь ваше поле деятельности еще более сужается. Обычно субд с средних/больших системах работают как отдельный, как минимум, процесс и как максимум — хост(ы) (компьютер). Embedded БД (SQLite, etc.) юзаются когда нужно что-то мелкое локально хранить без разворота субд. Как вы сюда втиснетесь я даж не знаю... все сказанное — имхо.
я знаю что они так работают, в этом то и вся соль, я считаю что такая объектная БД может заменить собой часть внутреннего state-а приложения, предоставить ACID свойства для внутренних структур данных программы и, после того как будет работать распределенная репликация — позволить многим приложениям совместно обрабатывать общие данные. разве это плохо?
