Ты правда думаешь, что там в с этим злоебучим файлом работают:
а) на php
б) в один поток
в) без маппинга части данных в память
г) без дефрагментации
д) без разруливания для потоков локов
е) etc.
? ))))
Я не говорю, что идея плохая, я говорю, что реализация этой идеи на пхп без продумывания, с бухты барахты будет медленнее, чем обычная ФС, а при нормальной нагрузке не просто медненнее, а в тысячи раз медленнее. На пхп дак вообще, как бы не реализовыывали, какую бы хитроумную и сверхбыструю архитектуру не придумали, все равно ФС будет быстрее.
новые сообщения
ответы на мои сообщения
избранное
скрытые темы
случайный топик
открыть всё в новых вкладках
Форум → Программирование → Пыхнуть хотите? → Готовые решения → BlobStorage 0.1 Alpha :)
BlobStorage 0.1 Alpha :)
Страницы: ← Предыдущая страница →
-
Сообщения:
574
Репутация:
N
Группа:
Джедаи
-
Сообщения:
26646
Репутация:
N
Группа:
в ухо
6 ноября 2010 г. 20:20, спустя 3 минуты 54 секунды
Я не говорю, что идея плохая, я говорю, что реализация этой идеи на пхп без продумывания, с бухты барахты будет медленнее, чем обычная ФС, а при нормальной нагрузке не просто медненнее, а в тысячи раз медленнее. На пхп дак вообще, как бы не реализовыывали, какую бы хитроумную и сверхбыструю архитектуру не придумали, все равно ФС будет быстрее.
пхп - write client, причем тут чтение? :)
чтение прикольно модулем того же нгинкса сделать, вообще было бы ахуенно :)б) в один поток
ага, на винте 30 головок читают один файл, не смеши, при конкурентном доступе там тоже не все так сказочно :)Спустя 111 сек.а) чем хуже того же си?
б) похуистично, можно сервер написать типа бд, который будет работать с этими файлами и клиента к нему, а сервер уже следить за очередью и локами
в) зависит от размеров данных
г) при блочной записи блок в блок - откуда фрагментация?
д) ну можно сервер, но мы не фейсбук пишем
е) етс не катит :)Спустя 13 сек.
Сапожник без сапог -
Сообщения:
2706
Репутация:
N
Группа:
Адекваты
6 ноября 2010 г. 20:21, спустя 20 секунд
Nyaah, Мне просто стало интересна эта тема, вот и все :) Пофиг быстрее не быстрее, just for fun как говорится, и да, согласен с дудом на счет пхп как врайт клиента :) -
Сообщения:
2706
Репутация:
N
Группа:
Адекваты
6 ноября 2010 г. 20:35, спустя 14 минут 19 секунд
значит так,
контейнер: первые 4 байта это с какого байта начинается сама картинка, след. 4 байта это номер байта конца картинки, остальное это сериализованные данные в которых и уникальный идентификатор и все че хочешь :) -
Сообщения:
574
Репутация:
N
Группа:
Джедаи
6 ноября 2010 г. 20:37, спустя 2 минуты 19 секунд
чем хуже того же си?
наверно потому что си быстрее?при блочной записи блок в блок - откуда фрагментация?
Если делать хранилище только для добавления то все окей. А вот если решили заюзать эту приблуду для хранения картинок например, был у пользователя аватар размером 1000 байт, и лежал он в файле с оффсетом 10500 от начала, решил пользователь залить новый аватар, оказался он размером 1001 байт, хуле делать, старый затираем и смещаем все данные с оффсетом 10500 + 1000 либо вправо на 1 байт, либо влево на 1000, записываем новые данные либо на старое место, либо в конец, а если файл размером гигабайт, то сдвагаем гиг считай, ради сраного одного байта…ну можно сервер, но мы не фейсбук пишем
А в чем профит то? Если не для высоких нагрузок, то для чего? )Work, buy, consume, die -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
6 ноября 2010 г. 20:48, спустя 11 минут
Если делать хранилище только для добавления то все окей. А вот если решили заюзать эту приблуду для хранения картинок например, был у пользователя аватар размером 1000 байт, и лежал он в файле с оффсетом 10500 от начала, решил пользователь залить новый аватар, оказался он размером 1001 байт, хуле делать, старый затираем и смещаем все данные с оффсетом 10500 + 1000 либо вправо на 1 байт, либо влево на 1000, записываем новые данные либо на старое место, либо в конец, а если файл размером гигабайт, то сдвагаем гиг считай, ради сраного одного байта…
да кому этот 1 байт сдался? я так даже и не собирался думать :)наверно потому что си быстрее?
может и сайты на нем будем писать тогда? в этой задаче скорость не важна, я тебя разочарую :) плохому танцору сам знаешь что мешает :)А в чем профит то? Если не для высоких нагрузок, то для чего? )
ну насколько я понял, ИМЕННО ЭТА тема просто фо фан - мозги напрячь другими словами :)Сапожник без сапог -
Сообщения:
574
Репутация:
N
Группа:
Джедаи
6 ноября 2010 г. 20:53, спустя 5 минут 11 секунд
Нас невозможно сбить с пути - нам похую, куда идти :-
=)Work, buy, consume, die -
Сообщения:
2706
Репутация:
N
Группа:
Адекваты
7 ноября 2010 г. 3:32, спустя 6 часов 38 минут 50 секунд
Блеать… stackoverflow :( потестил блеать новую версию с метаданными, блоб в 50 метров и в метаданных переполнение integer :(
-
Сообщения:
2706
Репутация:
N
Группа:
Адекваты
7 ноября 2010 г. 3:42, спустя 10 минут 11 секунд
И еще, пришел к умозаключению как устроить метаданные:
[4bytes=длина добавочных данных*][other_metadata]
[4bytes=размер собственно пикчи]
[picture]
*В добавочных данных валяется и айдишник и все что душе угодно))
Почему в мета нет указателя на начало пикчи? А нафига, при таком построении метаданных пикча начинается через:
[dataStart+4+other_metadata_length+4]Спустя 260 сек.Гаршок уже совсем не варит… -
Сообщения:
2706
Репутация:
N
Группа:
Адекваты
7 ноября 2010 г. 4:52, спустя 1 час 9 минут 36 секунд
Хм, если подумать над тем что делает fseek() то метод хранения инфы в блобе как говорит дуд мягко говоря ниочем))) повернем головку харда для чтения 4-ех байт, потом еще разок повернем для чтения еще 4-ех байт, надо метаинфу - еще раз повернем…
А если делать как я сделал с самого начало то поворачивать головку харда для чтения 1 пикчи надо только 1 раз, вся метаинфа хранится в переменной, следовательно и доступ к ней куда быстрее, нежели читать ее из файла + меньше хлопот для харда :)
Ну или я опять что-то упустил/ступил :) -
Сообщения:
26646
Репутация:
N
Группа:
в ухо
7 ноября 2010 г. 8:20, спустя 3 часа 27 минут 53 секунды
Хм, если подумать над тем что делает fseek() то метод хранения инфы в блобе как говорит дуд мягко говоря ниочем))) повернем головку харда для чтения 4-ех байт, потом еще разок повернем для чтения еще 4-ех байт, надо метаинфу - еще раз повернем…
А если делать как я сделал с самого начало то поворачивать головку харда для чтения 1 пикчи надо только 1 раз, вся метаинфа хранится в переменной, следовательно и доступ к ней куда быстрее, нежели читать ее из файла + меньше хлопот для харда :)
кто мешает начиная со сдвига считать например 8 килобайт? может тебе повезет и эти 8 килобайт не только метаинфу содержать будут, еще и данные туда попадут :)Сапожник без сапог -
Сообщения:
2706
Репутация:
N
Группа:
Адекваты
-
Сообщения:
5210
Репутация:
N
Группа:
Джедаи
-
Сообщения:
2706
Репутация:
N
Группа:
Адекваты
Страницы: ← Предыдущая страница →
Пожалуйста, авторизуйтесь, чтобы написать комментарий!