RavenDB в «одноразовых» приложениях

На выходных попробовал RavenDB на небольшой задаче обработки массива документов. Документов было не очень много — порядка 50К, их обработка — задача разовая, но её длительность получалась однозначно порядка 10 часов, плюс всё это отлично параллелилось.
Поэтому возникла мысль загнать все эти документы в БД, чтобы без проблем сохранять промежуточные результаты и не волноваться за exception’ы, безвозвратно прерывающие обработку 10-часового процесса в самом конце :)
Raven-Embedded видился неплохим кандидатом для такого использования, поскольку позволял не париться с маппингами, быстро «установить» БД, просто добавив nuget пакет, позволял динамически добавлять в документы новые структуры данных (результаты обработок) ну и по идее должен был быстро работать :)
Что же из всего этого получилось?

Сразу оговорюсь, что использовал последнюю Prerelease-версию.

Мой код, в общих чертах, представлял из себя выборку и обработку блоков по 100 документов, предварительно внесенных в БД.
Выглядело это как-то так (опуская обработку ошибок и некоторые мелкие детали):

lock (_lockObject) {
	//получаем список необработанных домов.
	houses = session.Query<HouseInfo>()
				.Where(x => x.State == HouseInfo.DownloadState.NotStarted)
				.Customize(x => x.WaitForNonStaleResultsAsOfNow())  // необходимо, чтобы дома "недавно" помеченные как ParseStarted не попали на повторную обработку
				.Take(100).ToList();
				
	//помечаем дома, для которых начата обработка
	houses.ForEach(x =>
						{
							x.State = HouseInfo.DownloadState.ParseStarted;
						});
	session.SaveChanges();
}

foreach (var house in houses) {
	//производим обработку
	houses.ParsedData = ParseData(house);
	//переводим в завершенное состояние
	houses.State = HouseInfo.DownloadState.Finished;
}
session.SaveChanges();	

Первой неожиданностью стала проблема с .Customize(x => x.WaitForNonStaleResultsAsOfNow()). Точнее, с её изначальным отсутствием :) Из-за этого два соседних потока регулярно принимали в обработку одни и те же документы (потому что измененный State не успевал попасть в индекс). Проблема «невалидных» индексов вообще стала достаточно серьезной в контексте использования Рейвена в небольших «одноразовых» приложениях.
В моем случае все индексы создавались «динамически» (то есть я не писал MapReduce-классов), поэтому индексы получали статус «временных», и по выходу из приложения, насколько я понял, не сохранялись. Соответственно при новом запуске и попытке выполнить запрос типа session.Query().OrderBy(x => x.IntId).Take(50000).ToList() индекс создавался заново, и мне легко возвращалась лишь половина из существующих документов (из тех, что успели проиндексироваться). Это частенько вводило в замешательство :)

Второй большой проблемой стала производительность БД в контексте использования WaitForNonStaleResults. С учетом того, что обработка блоков в 100 документов занимала не слишком много времени (порядка 3-4 секунд на 100 документов), основным «тормозом» стала как раз выборка данных. Пауза на запросе достигала 15 секунд, что меня весьма печалило.
К концу обработки (где-то на 35К документе) Рейвен раскочегарился и сократил «зависания» до 1-2 секунд, что, в общем-то, вполне приемлемо, однако возможно, что это продлилось бы недолго :)

В сухом итоге впечатления от RavenDB Embedded:
+ очень быстрый старт (установка nuget-пакета), отсутствие маппингов;
+ удобный и понятный синтаксис запросов (знакомый всем linq)
— производительность при последовательных операциях записи/чтения, при строгой необходимости актуальности данных
— несколько непривычный синтаксис запросов в Raven Studio (lucene, a не SQL или linq)
В принципе поставленную задачу Рейвен решил.

В общем-то, задачу оптимизации WaitForNonStaleResults также можно было решить, если в запросах проверять не меняющийся State, а, допустим, id и обрабатывать документы в строго возрастающем порядке. Да, использование nosql даже в относительно простых случаях заставляет думать слегка «по-другому» в сравнении с миром sql :)

P.S. Ну и слегка непонятно, насколько легально такое «одноразовое» использование с учетом отсутствия у меня каких бы то ни было лицензий на Рейвен :)