Ну так я уже и сделал. Думал, может есть всё-таки более элегантное решение…
Спасибо!
Кстати, после какого размера партиции начинается проседание? с точностью до порядка, можете подсказать. 1K, 10K, 100K, 500K?
На Aerospike я тоже смотрел и даже пробовал, но это же БД для кеширования. Она все данные при старте в память грузит (по крайней мере так было 4 года назад) — не для этого решения.
Не встречал такую несколько лет назад. Сейчас посмотрю.
ScyllaDB — новая производительная NoSQL, совместимая с Apache Cassandra, от создателей Linux KVM
Если я правильно понимаю — я могу её использовать без изменений вместо C*? Просто вот так взять поменять адреса подключения и всё?
И там не будет проблем с Large Partiton? Или все перечисленные в статье недостатки останутся, только пошустрее будет? (если верить разработчикам )))
Очень интересная статья! Почему вы её не написали пару лет назад? ))) Почему-то очень мало находил в сети информации именно о возможных затыках работы с C*.
Получается, что C* нельзя в лоб использовать для хранения time-series данных, например значений данных с датчиков? (Я о проблеме Large Partition).
Другими словами структура данных вида:
У нас обоих парсер порезал типизированные генерики )))
В любом случае, явное приведение DbSet к IQueryable ничего не меняет, т.к. FirstOrDefault — это именно метод-расширение интерфейса IQueryable, а не DbSet.
Попробовал для интереса не интерфейс, а базовый класс — та же фигня, только теперь в ошибке написано, что не может привести объект к базовому классу.
Ваш пример также не работает, единственное отличие, я дописал материализацию запроса в массив:
public static T[] Range<T>(this IDbSet<T> set, HashSet<long> ids) where T : EntityBase
{
return set.Where(x => ids.Contains(x.Id)).ToArray();
}
Спасибо за статью.
Как раз недавно столкнулся с данной проблемой и применил решение №2, найденное на StackOverflow.
Поменял на ваш способ №4 — он не такой «магический» и действительно должен быть более оптимальным.
Увидел программист пианино. Он его рассмотрел и говорит: «Мда… клавиатура неудобная — в один ряд. Клавиш мало, половина из них функциональные, но вот shift ногой нажимать — это оригинально!»
Я работал в компании, где часть стандартов была очень похожа на некоторые из перечисленных. В результате один мой друг, который тоже работал в этой компании, по прошедствии трёх лет после ухода оттуда, даже в кругу друзей часто говорит «не готов ответить на твой вопрос» вместо «я не знаю».
Тут возник вопрос. К какому типу относится "омут памяти" из Гарри Поттера? )))
На stackoverflow сделано хорошо, как по мне: плюсовать можно просто так, а за минусование уменьшается твой рейтинг.
Спасибо!
Кстати, после какого размера партиции начинается проседание? с точностью до порядка, можете подсказать. 1K, 10K, 100K, 500K?
а это единственное, что мне нужно делать с этими данными
Если я правильно понимаю — я могу её использовать без изменений вместо C*? Просто вот так взять поменять адреса подключения и всё?
И там не будет проблем с Large Partiton? Или все перечисленные в статье недостатки останутся, только пошустрее будет? (если верить разработчикам )))
Получается, что C* нельзя в лоб использовать для хранения time-series данных, например значений данных с датчиков? (Я о проблеме Large Partition).
Другими словами структура данных вида:
является очень и очень неэффективной.
Что можете посоветовать для данного случая, основываясь на вашем опыте?
А можно об этом поподробнее? Или ссылку скиньте, плз.
ТАК ДЕЙСТВИТЕЛЬНО РАБОТАЕТ!
Что-же получается, можно обойтись и без упрощалки экспрешенов.
Спасибо! [])
и да, я проверял — вызывается метод-расширение именно IQueryable интерфейса. Ну и потом, я же EF и использую, а не Linq2Sql
Гипотеза интересная, но…
выдаёт ту же ошибку (
В любом случае, явное приведение DbSet к IQueryable ничего не меняет, т.к. FirstOrDefault — это именно метод-расширение интерфейса IQueryable, а не DbSet.
Думаю, что ваш код работает, потому что подготовленный IQueryable уходит в ODataProvider,
который дополнительно преобразовывает выражение.
Ваш пример также не работает, единственное отличие, я дописал материализацию запроса в массив:
Как раз недавно столкнулся с данной проблемой и применил решение №2, найденное на StackOverflow.
Поменял на ваш способ №4 — он не такой «магический» и действительно должен быть более оптимальным.
Когда-то это читал в отдельной книжечке — захватывало почище детективов.