ANS>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql? G>Ни в чем. Другой случай. Одна машина (!) G>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало. G>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?
Берем такой NoSQL, который имеет такой же лог
Но вообще-то да. Обычно NoSQL'и теряют как минимум одну из букв в ACID
ANS>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql? G>Ни в чем. Другой случай. Одна машина (!) G>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало. G>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?
Здравствуйте, gandjustas, Вы писали:
ANS>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql? G>Ни в чем. Другой случай. Одна машина (!) G>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало. G>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?
Я просто намекну, что Durability даёт _абсолютную_ гарантию. Второе, ты утверждал, что сможешь понять, какие именно транзакции пропали за эти 5 сек. Как?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Andrei N.Sobchuck, Вы писали: ANS>>>Здравствуйте, gandjustas, Вы писали: G>>>>Ты вообще о чем? Где теряются гарантии, покажешь? ANS>>>Тут
. ANS>>>>>ACID, кстати, тоже не выполняется, но программист (в данном случае gandjustas) то думает, что выполняется. G>>>>Покажи где он не выполнгяется. ANS>>>ACID гарантирует, что мы можем прочитать, то что записали? В любой момент времени, а не когда-то в необозримом будущем? G>>Можем. Select по ключу.
ANS>... и съел мой мозг
. А мог бы сказать, что не нужно читать то, что ты только записал. Ведь оно и так у тебя есть.
Нужно — читай. Тебе никто не мешает. Ты только полнотекстовым поиском не сможешь сразу ничего найти, если сам не приложишь усилия по его построению.
У тебя тут есть выбор.
Здравствуйте, Mamut, Вы писали:
ANS>>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql? G>>Ни в чем. Другой случай. Одна машина (!) G>>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало. G>>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?
M>Берем такой NoSQL, который имеет такой же лог
Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.
ANS>>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql? G>>Ни в чем. Другой случай. Одна машина (!) G>>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало. G>>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?
M>OrientDB иммет ACID M>Neo4J позволяет ACID
M>Всякие ОО-базы тоже позволяют. Тут: http://nosql-database.org/
Ну значит их и стоит использовать.
Я бы например не решился поднимать решение на NoSQL без Durability на одной машине. А поднимать сразу кластер — как-то накладно.
50% моих решений я без геморроя разворачиваю на shared хостинге, там уж точно NoSQL кластеров не видать.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
ANS>>>Простая ситуация: всё пропало, бекапы 12-часовой давности. В чем разница между ACID и NoSql? G>>Ни в чем. Другой случай. Одна машина (!) G>>MS SQL c Transaction Log Backup каждые 5 секунд, NoSQL с любыми средствами резервного копирования. Все пропало. G>>MS SQL могу до 5 секунд восстанавливать, с NoSQL что делать будем?
ANS>Я просто намекну, что Durability даёт _абсолютную_ гарантию.
Что ты имеешь ввиду?
ANS>Второе, ты утверждал, что сможешь понять, какие именно транзакции пропали за эти 5 сек. Как?
Где я такого утверждал? Я вообще catastrophic failure не рассматривал, это ты начал.
А вот незавершение дисковых операций при выключении компа, аппаратные ошибки итп. Особенно в ситуации где ты арендуешь железо — очень вероятны.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.
ANS>Transaction Log — это не единственная реализация durability, это оптимизация.
Не понимаю что ты хочешь сказать. Чуть менее чем во всех современных СУБД durability обеспечивается логом транзакций.
ANS>Более того, как я показал
Здравствуйте, gandjustas, Вы писали:
G>>>Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.
ANS>>Transaction Log — это не единственная реализация durability, это оптимизация. G>Не понимаю что ты хочешь сказать. Чуть менее чем во всех современных СУБД durability обеспечивается логом транзакций.
Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести.
ANS>>Более того, как я показал
, durability оно не обеспечивает. G>Ты там ничего не показал.
Либо у тебя один винт и нету никакой D. Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично. Или практика философов не интересует?
M>>OrientDB иммет ACID M>>Neo4J позволяет ACID
M>>Всякие ОО-базы тоже позволяют. Тут: http://nosql-database.org/
G>Ну значит их и стоит использовать.
G>Я бы например не решился поднимать решение на NoSQL без Durability на одной машине. А поднимать сразу кластер — как-то накладно.
Это камень в огород MongoDB Они вообще гарантируют отсутствие Durability на одной машине
G>50% моих решений я без геморроя разворачиваю на shared хостинге, там уж точно NoSQL кластеров не видать.
Здравствуйте, gandjustas, Вы писали:
G>>>Вот скажи честно, сколько занимает в твоем решении чтение данных в память? Как часто приходится перечитывать? M>>Сколько раз говорить о том, что нет чтения данных в пямять. Индексация занимает 15 минут. G>И как часто она выполняется?
Раз в сутки. К принципе можно запускать каждый час, только это никому не надо и нисколько не критично
G>Теперь открою еще одну тайну. Работа субд аналогична тому что ты будешь делать переиндексацию на каждое изменение. G>Поэтому SQL уже порвал твой код в разы.
Да он порвал мой код в разы, но на другой задаче Ибо требование делать переиндексацию на каждое изменение не критично нисколько. А вот решить именно нашу задачу с использованием SQL никто у нас не смог. Что говорит о том, что писать NoSQL проще. По крайней мере для некоторых.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести.
* Fsync() every time a new command is appended to the append log file. Very very slow, very safe.
* Fsync() one time every second. Fast enough, and you can lose 1 second of data if there is a disaster.
* Never fsync(), just put your data in the hands of the Operating System. The faster and unsafer method.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, gandjustas, Вы писали:
G>>>>Не имеет такого же лога. Transaction Log — это реализация durability, которой во многих NoSQL хранилищах нету.
ANS>>>Transaction Log — это не единственная реализация durability, это оптимизация. G>>Не понимаю что ты хочешь сказать. Чуть менее чем во всех современных СУБД durability обеспечивается логом транзакций.
ANS>Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести.
Бред. Как ты откатывать транзакцию будешь без лога?
ANS>>>Более того, как я показал
, durability оно не обеспечивает. G>>Ты там ничего не показал.
ANS>Либо у тебя один винт и нету никакой D.
Ты неверно понимаешь слово Durability.
ANS>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично.
ACID вообще не коррелирует с CAP.
ANS>Или практика философов не интересует?
Практика это зачастую одна машина с БД, а CAP и мега-распределенные системы это теория.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>>>Вот скажи честно, сколько занимает в твоем решении чтение данных в память? Как часто приходится перечитывать? M>>>Сколько раз говорить о том, что нет чтения данных в пямять. Индексация занимает 15 минут. G>>И как часто она выполняется?
M>Раз в сутки. К принципе можно запускать каждый час, только это никому не надо и нисколько не критично
G>>Теперь открою еще одну тайну. Работа субд аналогична тому что ты будешь делать переиндексацию на каждое изменение. G>>Поэтому SQL уже порвал твой код в разы.
M>Да он порвал мой код в разы, но на другой задаче Ибо требование делать переиндексацию на каждое изменение не критично нисколько. А вот решить именно нашу задачу с использованием SQL никто у нас не смог. Что говорит о том, что писать NoSQL проще. По крайней мере для некоторых.
А причем тут NoSQL? Ты просто свел задачу к той, которую БД не умеет решать, и написал решение сам.
Кстати полнотекстовый поиск не пробовал использовать?
Здравствуйте, gandjustas, Вы писали:
ANS>>Durability обеспечивается не логом транзакций, а записью на винт до возвращения ответа пользователю. Лог транзакций позволяет превратить множество записей рандомных блоков в малое колличество последовательных. А все остальные блоки можно записать позже асинхронно. Т.е. синхронно пишет быстро, а потом асиннхронно медленно. Можно выкинуть лог. ACID же о скорости ничего не говорит. Просто будет не совсем практично. А. Если у тебя БД организована так что есть один только как бы "лог", то отдельный лог можно и не вести. G>Бред. Как ты откатывать транзакцию будешь без лога?
Это сто процентов. Я собственно сразу заявил, что именно то Durability, которое в ACID никому не нужно. Пользователь утрётся и введёт данные заново. За 5 сек, 5 мин, 5 дней. А нужно нам что попроще. Просто чтобы спать спокойно, ибо программист и так никакой ответственности ни за что не несёт. А если кому нужно нормальное "Durability" и он попытается его обеспечить, то скажем что просто никто в RDBMS ничего не понимает. И продолжим спать спокойно.
ANS>>Либо не один и тогда, скорее всего, нету CAP-Availability. ACID конечно ничего о доступности не говорит, но это же не совсем практично. G>ACID вообще не коррелирует с CAP.
D в ACID == C в CAP. Но не в этом дело. Дело в том, что с практической точки зрения люди всё равно заботятся о доступности.
ANS>>Или практика философов не интересует? G>Практика это зачастую одна машина с БД, а CAP и мега-распределенные системы это теория.
. А потом ставят какой-нибудь memcached и работают с ним так: http://www.majordojo.com/2007/03/memcached-howto.php . То что всё иногда ломается — так сделаем круглые глаза, у нас же ACID и всё гарантировано. Почему ты запрещаешь сделать инструмент, который убережёт от таких ошибок?
Здравствуйте, Mamut, Вы писали:
M>В общем, NoSQL постепенно приходит к durability Особенно в наиболее известных/распространенных проектах
Это и понятно. Зародилось оно в условиях когда есть кластер. А там, имхо, синхронная репликация и быстрее и гораздо надёжнее, чем какие-то там винты. А людям хочется эти сервера локально поднимать. Хотя, мне кажется, что будущее тут это БД-как-сервис.
Здравствуйте, Mystic, Вы писали:
M>Как минимум еще надо все это поддерживать. Во-вторых, в самом тяжелом случае, когда надо вернуть миллион/полтора записей, одни только вычисления агрегатных функций, написанные на чистом C, занимают 50% времени. Т. е. если предположить, что поиск данных занимает нуль секунд, а производительность вычислений агрегатных функций совпадает с чистым C, то мы ускоримся в два раза.
Ну... А зачем кубы придумали? На худой конец — триггеры.
M>И в третьих, как тогда писать SQL-запросы: Если у нас items имеет вид item_id, tag1, tag2, tag3, ..., tag100 M>то как выбрать все записи, у которых есть в tag встречается и 10 и 25? Писать M>
M>WHERE (tag1=10 OR tag2=10 or tag3=10 OR ... ) AND (tag1=25 OR tag2=25 or tag3=25 OR ... )
M>
