Флейм
GameDev.ru / Флейм / Форум / Монолитная база данных VS простые файлы (2 стр)

Монолитная база данных VS простые файлы (2 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
kiparУчастникwww13 фев. 20180:30#15
-=MASTER=-
Мьютексы на много порядков быстрее доступа к диску.
thevladПостоялецwww13 фев. 20180:30#16
beejah
да, я тоже думаю... где же все таки дно...
BUzerПостоялецwww13 фев. 20183:32#17
С файловой системой нет гарантии атомарности. Если произошёл сбой, то файл может не дописаться, поэтому надо наворачивать проверки на контрольные суммы и тому подобное.
-=MASTER=-Удалёнwww13 фев. 20189:48#18
thevlad, каким же надо быть лохом, что бы постить в тредах, где тебя мягко говоря не ждут и попросили не постить, сказав, что твоё присутствие здесь совсем не уместно... Это всё равно что на улице говорят мужики... подходит к ним какое-то чмо опущенное и просит: "ну поговорите со мной пожалуйста, я с мамой поругался...", ему в ответ - "иди на..хуй" и пинок под зад, а он опять на коленях ползёт и просить слёзно..."ну пожалуйста...."...  Пиз..ц, у меня слов нет )))

kipar
> Мьютексы на много порядков быстрее доступа к диску.
Они то быстрее, но если у тебя хотя бы 1 000 000 узлов, которые постоянно что-то пишут на хард, наверное всё таки они дадут о себе знать

BUzer
> С файловой системой нет гарантии атомарности. Если произошёл сбой, то файл
> может не дописаться, поэтому надо наворачивать проверки на контрольные суммы и
> тому подобное.
В случае монолитного файла БД - тоже самое. Вообще на самом деле все БД в основном хранятся в памяти и и весь вопрос стоит в частоте свопа данных на хард.
Хмм... Да, наверное всё таки у монолитного файла больше плюсов, чем минусов...

Кстати, допустим в памяти лежит БД целиком, то есть монолитный блок памяти. Допустим каждая ячейка имеет размер на кратный степени двойки и он не равен размеру одной транзакции чтения шины памяти.. Так вот, если я без блокировок буду в одну ячейку записывать что-то, а из соседней в это время - читать, не будет ли из-за этого повреждения данных? или будут просто тормоза на уровне контроллера... ?

Правка: 13 фев. 2018 9:49

-=MASTER=-Удалёнwww13 фев. 201810:16#19
Хотя с другой стороны, вот есть у тебя монолитный файл БД, он весь в ОЗУ, ноды делают изменения и после каждого ты хочешь сохранить эти изменения на харде... По сути, каждая операция сохранения == открытие/закрытие файла, что не быстро, хотя... если открывать и закрывать всегда один файл, это ж будет быстрее, чем тыкать голову допотопного харда всё время в разные точки
SuperInoyПостоялецwww13 фев. 201810:50#20
-=MASTER=-
> Они то быстрее, но если у тебя хотя бы 1 000 000 узлов, которые постоянно
> что-то пишут на хард, наверное всё таки они дадут о себе знать
что лучше, 1М*1нс или 1М*1мс?
-=MASTER=-
> и после каждого ты хочешь сохранить эти изменения на харде
А нахера после каждого-то? Что у тебя там такого сверхценного, что нельзя закешировать и обновлять раз в n секунд?

Правка: 13 фев. 2018 10:51

-=MASTER=-Удалёнwww13 фев. 201811:03#21
SuperInoy
> А нахера после каждого-то? Что у тебя там такого сверхценного, что нельзя
> закешировать и обновлять раз в n секунд?
Да, ты прав, на сервере сохранять каждый пшик - бредятина... На сервере, я полагаю, нужно брать умный ИБП, который в случае отключения питания, даст сигнал софту и тот по-быстрому свопнет всё на хард.
Так что наверное реализую монолитную концепцию.

Правка: 13 фев. 2018 11:04

thevladПостоялецwww13 фев. 201812:14#22
-=MASTER=-
> thevlad, каким же надо быть лохом, что бы постить в тредах, где тебя мягко
> говоря не ждут и попросили не постить, сказав, что твоё присутствие здесь
> совсем не уместно... Это всё равно что на улице говорят мужики... подходит к
> ним какое-то чмо опущенное и просит: "ну поговорите со мной пожалуйста, я с
> мамой поругался...", ему в ответ - "иди на..хуй" и пинок под зад, а он опять на
> коленях ползёт и просить слёзно..."ну пожалуйста...."... Пиз..ц, у меня слов
> нет )))
ну я честно говоря, забился тебе больше не писать... но ты не перестаешь удивлять. :facepalm:
дальше уже наверное некуда, так что усбогойся...
kiparУчастникwww13 фев. 201812:34#23
-=MASTER=-
> это ж будет быстрее, чем тыкать голову допотопного харда всё время в разные
> точки
для харда это даже не смешно. Если двигать головку туда-сюда, параллельная записи выходит в разы дольше последовательной. Кроме ССД ясно что нет смысла что-то рассматривать. Но даже использовать ссд чтоб не заморачиваться с мьютексами - звучит как лечение перхоти топором.
> если открывать и закрывать всегда один файл, это ж будет быстрее
можно сбрасывать на диск не закрывая, ака flush.
-=MASTER=-Удалёнwww13 фев. 201813:11#24
kipar
> можно сбрасывать на диск не закрывая, ака flush.
Частично менять файл - тот ещё геммор... Да и потом, нужно будет согласиться на максимальную длину полей, что бы формат оставался константным... Скорее всего придётся переписывать весь файл, а если он гигов 10 ...
graphITПостоялецwww13 фев. 201813:13#25
Обычно для ускорения записи, данные пишут в память, а в журнал (коммит лог) пишут операции изменения данных, а после этого данные из памяти в фоне сбрасывают на диск. Собственно скорость записи (для клиента бд) получается равна последовательной скорости записи в файл на диск. Так например кассандра работает.
Можно вообще отказаться от записи на диск, если бд обеспечивает долговечность за счет распределенности.

Правка: 13 фев. 2018 13:13

beejahПостоялецwww13 фев. 201814:16#26
-=MASTER=-
> поясни свою мысль хоть
Не могу. Серьезно, не могу.
-=MASTER=-Удалёнwww13 фев. 201815:41#27
beejah
> Не могу. Серьезно, не могу.
если ты не в состояние даже свою мысль выразить, так и заходи в тред.
P.S.: туалет есть во флейме
Sbtrn. DevilПостоялецwww13 фев. 201816:14#28
У нас на одном проекте начинали с хранения юзерских онлайновых сейвов в файлах. Когда их счёт пошёл на миллион, пришлось перевести хранение в базу. Потому что сейвы небольшие, а у файлов оверхеды, и за счёт этого что-то типа 4Гб чистых данных занимало 12Гб на диске. С файлами сначала было удобнее, в смысле работы с ними через файловое апи, а также открытия/просмотра/заливки штатными файл-менеджерами. Но когда счёт пошёл на см. выше, это удобство сошло на нет, потому что один только список закачивался много минут, и получить его осиливали не только лишь все менеджеры.
beejahПостоялецwww13 фев. 201816:19#29
Sbtrn. Devil
> У нас на одном проекте начинали с хранения юзерских онлайновых сейвов в файлах. Когда их счёт пошёл на миллион, пришлось перевести хранение в базу.
Да тут при любом количестве файлов уже гемороя и экзотики огребаешь - бэкап, миграция, да тупо оперативная выборка, вот это все.
Страницы: 1 2 3 4 5 6 7 Следующая »

/ Форум / Флейм / Программирование

2001—2018 © GameDev.ru — Разработка игр