Комментарии 31
Вот к примеру для монги:
1) надо скачать архив
2) распаковать
3) запустить 1 экзешник с нужными ключами.
>Tarantool.CSharp
Подразумевает что я на VisualBasic.NET или F# должен искать Tarantool.VBasic и Tarantool.FSharp? Впервые вижу ограниченный по языку Nuget пакет.
Не сказал бы что с Linux подсистемой — это именно "пляски". Данная подсистема является всё-таки встроенной функциональностью Windows 10 и запустить почти любой продукт в ней можно достаточно быстро (это дело минут).
С другой стороны если бы был exe-шник, то не потребовалось бы писать так много про установку Tarantool. Пока, к сожалению, либо Windows Subsystem for Linux, либо Docker.
При установленном Docker всё вообще запускается одной командой в один шаг. Куда уж проще:
> docker run -d tarantool/tarantool:1.7
>Tarantool.CSharp
Возможно выбрано не самое удачное название NuGet пакета. Каких-то привязок именно к C# в исходном коде я не нашёл. Поэтому в Visual Basic и F# нужно подключать этот же пакет.
А если у меня 8 или 7? Около 2/3 статьи это описание процесса установки.
Ну, давайте не будем смотреть на лучших, в плане простоты установки, а посмотрим на «зрелый» продукт postgresql:
a) качаем инсталлятор -> next, next, next, finish
б) качаем архив, распаковываем, запускаем initdb, запускам постгрес через pg_ctl
Моё скромное мнение, что для Windows надо поддерживать один из этих двух вариантов установки, иначе продукт еще не готов.
Не могу не согласиться, что иметь нативные exe-шники для Windows — это лучше чем не иметь их, с этим трудно поспорить. Но в статье я описал свой опыт, а у меня каких-либо проблем с использованием Tarantool при разработке на Windows не возникло.
Я не согласен с тем, что всегда лучше иметь нативные exe. Лучше — только в том случае, если в production будет тоже windows server стоять, а не linux.
p.s. докер и виртуализация это не «простое» решение. Решение это Windows бинарники и отсутствие зависимостей.
У вас есть несколько ошибочных допущений.
- Вы предполагаете, что я являюсь членом команды разработки Tarantool. Это не так. Я даже не работаю в Mail.Ru или любой другой компании в России. Я просто сторонний человек, считающий необходимым делиться своими наработками с миром.
- Все остальные коммитеры в коннектор (на момент написания комментария: 18 февраля 2017го года) — мои сотрудники, тоже не работающие в компании Mail.Ru.
После дисклеймеров выше (которые были, как мне кажется, очевидными), я могу сказать следующее (что может не соответствовать мнению команды разработки Тарантула, т.к. я не являюсь её частью):
- docker run — прекрасное и простое решение.
- Бинарник под винду вводит разработчиков в заблуждение, что под Windows будет всё прекрасно работать.
Дальше мы можем безусловно долго и упорно спорить, непонятно только зачем.
Да, там Linux образ. А правда, какие преимущества будут от запуска в Azure на Windows виртуалках вместо Linux виртуалок?
Добрый день.
Я — один из авторов коннектора. Спасибо за обратную связь, было очень интересно почитать, как им пользуются вне компании.
- Коннектор находится в стадии разработки. Он изначально проектировался как низкоуровневое решение, наиболее близкое к спецификации протокола и его lua реализации.
- После релиза инструментария для .net core 7 марта я планирую добавить упрощённую сериализацию POCO в MsgPack.Light. С помощью этого мы упростим работу с коннектором (все эти TarantoolTuple уйдут).
- Идентификатор поменяем, я не думал, что это может вводить в заблуждение.
- Я не считаю ORM хорошим решением, поэтому сложных ORM (сбор объекта по нескольким спейсам, етс), поддерживать внутри коннектора скорее всего не будем. Если только не будет очень большого спроса на него.
берём .net, берём тарантул
всё что было в .net переписываем на lua
выкидываем .net
????
PROFIT
Я конечно не призываю всё переписать на Lua (хотя технически так можно сделать). Идея в том, что не стоит рассматривать Tarantool исключительно как простое хранилище данных. У него гораздо больше возможностей. Поэтому можно обращаться к Tarantool напрямую из .NET, а можно построить REST-сервис и обращаться уже к нему. Я показал оба эти варианта. Естественно основная часть бизнес-логики в нашем случае на C#.
Но, как оказалось, ASP.NET Core приложение не делает практически ничего, кроме передачи данных между пользователями микросервиса и Tarantool
Фраза показалась немного грустной.
Да, надо поправить формулировку. Речь идёт про конкретный микросервис авторизации и аунтетификации. Потребители микросервиса естественно на .NET.
Так как наш сервис, использующий Tarantool и .NET Core c Linux, ещё в процессе разработки, то нормальных данных по нагрузке нет.
Но я склонен верить результатам тестов ASP.NET
(конечно потом проверю всё сам для нашего сервиса):
https://github.com/aspnet/benchmarks
И Tarantool:
https://habrahabr.ru/company/mailru/blog/281841/
Даже базовый пример в коннекторе показывает, что вы неправы. Что вам кажется не работающим?
На самом деле ответ на этот вопрос потянет на целую статью. На эту тему есть поста на facebook: https://www.facebook.com/leo.yuriev/posts/553318381522430?pnref=story
Но основное — это конечно то, что Tarantool — это полноценная СУБД:
Redis ориентирован на in-memory обработку с возможностью сохранять данные периодически или при остановке. Тарантул же может обеспечивать постоянную консистентность данных на диске.
Тарантул: Кроме снимков (aka snapshots, checkpoints, syncpoints) есть полноценный WAL (write ahead log). Соответственно "из коробки" можно обеспечить сохранность данных после каждого изменения.
Redis: Фактически есть только снимки базы. Технически есть AOF (append-only лог, в который пишутся все операции), но он требует ручного управления, в том числе ручного восстановления.
Проще говоря, в Redis вам необходимо "ручками" переодически приостанавливать сервер, формировать снимки и архивировать AOF.
Приходите на митап, я расскажу. Мы как раз с Редиса съезжаем.
Неоднократно замечаю, что продукт интересен, люди просят, а дистрибутива все нет.
Использование Tarantool в .NET-проекте на Windows