Сообщение Re[7]: Подскажите самые быстрые коллекции от 22.02.2016 13:49
Изменено 23.02.2016 16:18 WolfHound
Здравствуйте, okon, Вы писали:
O>Здравствуйте, Win32nipuh, Вы писали:
W>>Здравствуйте, okon, Вы писали:
O>>>Здравствуйте, Win32nipuh, Вы писали:
W>>>>Здравствуйте, Don Reba, Вы писали:
DR>>>>>Здравствуйте, Win32nipuh, Вы писали:
W>>>>>>А смысл это все иметь в памяти?
W>>>>>>Почему бы не использовать, например,SQLite ?
DR>>>>>Вопрос был о самых быстрых коллекциях, а не о самых медленных.
W>>>>так как вопрос поставлен расплывчато, то еще кто знает, что будет быстрее в итоге.
O>>>Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ?
O>>>SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?
W>>Думаю, что в некоторых случаях да, будет быстрее при обработке больших объемов.
W>>Подробности не описаны в вопросе ТС.
O>А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление
С одной стороны — да, но с другой — для того, чтобы "любой алгоритм применить" в своей программе надо его реализовать,а если есть желание и время, то можно и велосипед придумать.
Кстати, по поводу выборок, а также индексов и тормозов на обновлении:
Я на нашел у ТС данных откуда он берет данные, обновляет ли или только читает, возможно был невнимателен, зато нашел такое
"необходимо иметь быстрый доступ к экземпляру"
То есть все-таки чтение.
И да, можно еще добавить Redis, все от задачи зависит.
O>Здравствуйте, Win32nipuh, Вы писали:
W>>Здравствуйте, okon, Вы писали:
O>>>Здравствуйте, Win32nipuh, Вы писали:
W>>>>Здравствуйте, Don Reba, Вы писали:
DR>>>>>Здравствуйте, Win32nipuh, Вы писали:
W>>>>>>А смысл это все иметь в памяти?
W>>>>>>Почему бы не использовать, например,SQLite ?
DR>>>>>Вопрос был о самых быстрых коллекциях, а не о самых медленных.
W>>>>так как вопрос поставлен расплывчато, то еще кто знает, что будет быстрее в итоге.
O>>>Вы думаете что СУБД , особенно "СУБД" SQLLite будет работать быстрее чем программа данные в памяти обрабатывать ?
O>>>SQLLite знает секретный алгоритм быстрого поиска ли сортировки ?
W>>Думаю, что в некоторых случаях да, будет быстрее при обработке больших объемов.
W>>Подробности не описаны в вопросе ТС.
O>А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление
С одной стороны — да, но с другой — для того, чтобы "любой алгоритм применить" в своей программе надо его реализовать,а если есть желание и время, то можно и велосипед придумать.
Кстати, по поводу выборок, а также индексов и тормозов на обновлении:
Я на нашел у ТС данных откуда он берет данные, обновляет ли или только читает, возможно был невнимателен, зато нашел такое
"необходимо иметь быстрый доступ к экземпляру"
То есть все-таки чтение.
И да, можно еще добавить Redis, все от задачи зависит.
Re[7]: Подскажите самые быстрые коллекции
Здравствуйте, okon, Вы писали:
O>А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление
С одной стороны — да, но с другой — для того, чтобы "любой алгоритм применить" в своей программе надо его реализовать,а если есть желание и время, то можно и велосипед придумать.
Кстати, по поводу выборок, а также индексов и тормозов на обновлении:
Я на нашел у ТС данных откуда он берет данные, обновляет ли или только читает, возможно был невнимателен, зато нашел такое
"необходимо иметь быстрый доступ к экземпляру"
То есть все-таки чтение.
И да, можно еще добавить Redis, все от задачи зависит.
O>А какая разница , СУБД такая же программа она оперирует данными в памяти или на диске. И быстрее она может работать если работает с более быстрым источником данных например у нее данные закешированны в памяти и память эта шустрее декстопной в 2-3 раза, но к SQLLite это не относится она локальная. В остальном любой алгоритм можно применить в своей программе и СУБД будет проигрывать, т.к. будет лишний еще действо — чтение из этой СУБД не говоря уже о записи , захотите быстрый поиск нужен будет индекс, добавите индекс начнет тормозить обновление
С одной стороны — да, но с другой — для того, чтобы "любой алгоритм применить" в своей программе надо его реализовать,а если есть желание и время, то можно и велосипед придумать.
Кстати, по поводу выборок, а также индексов и тормозов на обновлении:
Я на нашел у ТС данных откуда он берет данные, обновляет ли или только читает, возможно был невнимателен, зато нашел такое
"необходимо иметь быстрый доступ к экземпляру"
То есть все-таки чтение.
И да, можно еще добавить Redis, все от задачи зависит.