А есть способ разворачивания Tarantool без плясок с линукс подсистемой?

Вот к примеру для монги:
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# нужно подключать этот же пакет.

>функциональностью Windows 10
А если у меня 8 или 7? Около 2/3 статьи это описание процесса установки.

Ну, давайте не будем смотреть на лучших, в плане простоты установки, а посмотрим на «зрелый» продукт postgresql:
a) качаем инсталлятор -> next, next, next, finish
б) качаем архив, распаковываем, запускаем initdb, запускам постгрес через pg_ctl

Моё скромное мнение, что для Windows надо поддерживать один из этих двух вариантов установки, иначе продукт еще не готов.

Не могу не согласиться, что иметь нативные exe-шники для Windows — это лучше чем не иметь их, с этим трудно поспорить. Но в статье я описал свой опыт, а у меня каких-либо проблем с использованием Tarantool при разработке на Windows не возникло.

Я не согласен с тем, что всегда лучше иметь нативные exe. Лучше — только в том случае, если в production будет тоже windows server стоять, а не linux.

Большинство разработчиков сидят под Windows, потом под MacOS. Т.е. вам команде tarantool не нужны разработчики? Тогда Windows разработчикам будет не нужен tarantool, ведь они не смогут его легко развернуть на машине разработчика.

p.s. докер и виртуализация это не «простое» решение. Решение это Windows бинарники и отсутствие зависимостей.

У вас есть несколько ошибочных допущений.


  1. Вы предполагаете, что я являюсь членом команды разработки Tarantool. Это не так. Я даже не работаю в Mail.Ru или любой другой компании в России. Я просто сторонний человек, считающий необходимым делиться своими наработками с миром.
  2. Все остальные коммитеры в коннектор (на момент написания комментария: 18 февраля 2017го года) — мои сотрудники, тоже не работающие в компании Mail.Ru.

После дисклеймеров выше (которые были, как мне кажется, очевидными), я могу сказать следующее (что может не соответствовать мнению команды разработки Тарантула, т.к. я не являюсь её частью):


  1. docker run — прекрасное и простое решение.
  2. Бинарник под винду вводит разработчиков в заблуждение, что под Windows будет всё прекрасно работать.

Дальше мы можем безусловно долго и упорно спорить, непонятно только зачем.

Насколько я помню из постов про тарантул, он существует только под Linux, Windows версии просто нет. И сразу вопрос, а вообще есть в планах сделать нативную версию под Win?
А действительно существует потребность запускать его на windows-серверах? Без подковырок и издевательств спрашиваю. Просто может я чего не понимаю.

По поводу windows — он есть для Azure.
Azure не значит Win. В Azure Marketplace есть готовый образ, но там Linux.

Да, там Linux образ. А правда, какие преимущества будут от запуска в Azure на Windows виртуалках вместо Linux виртуалок?

Если проект на MS-стеке, то скорее всего админы умеют готовить windows server, а линукс — второй фактор неопределённости после тарантула. Два — уже много, уже «опасно тащить в продакшен». Про технические преимущества и недостатки ничего сказать не могу.

Мы при разработке используем Docker. Очень удобно.


Про своё отношение к Windows binary для tarantool я буду рассказывать на митапе. Приходите.

Добрый день.


Я — один из авторов коннектора. Спасибо за обратную связь, было очень интересно почитать, как им пользуются вне компании.


  1. Коннектор находится в стадии разработки. Он изначально проектировался как низкоуровневое решение, наиболее близкое к спецификации протокола и его lua реализации.
  2. После релиза инструментария для .net core 7 марта я планирую добавить упрощённую сериализацию POCO в MsgPack.Light. С помощью этого мы упростим работу с коннектором (все эти TarantoolTuple уйдут).
  3. Идентификатор поменяем, я не думал, что это может вводить в заблуждение.
  4. Я не считаю ORM хорошим решением, поэтому сложных ORM (сбор объекта по нескольким спейсам, етс), поддерживать внутри коннектора скорее всего не будем. Если только не будет очень большого спроса на него.

Не проще сделать нативный универсальный JSON path коннектор с отличиями (расширениями) касающимися системного кейспейса тарантула чтобы достукиваться запросами до любого доступного атрибута или списка нод?

Нормальная статья. Как приготовить тарантул и асп.нет:
берём .net, берём тарантул
всё что было в .net переписываем на lua
выкидываем .net

????
PROFIT

Я конечно не призываю всё переписать на Lua (хотя технически так можно сделать). Идея в том, что не стоит рассматривать Tarantool исключительно как простое хранилище данных. У него гораздо больше возможностей. Поэтому можно обращаться к Tarantool напрямую из .NET, а можно построить REST-сервис и обращаться уже к нему. Я показал оба эти варианта. Естественно основная часть бизнес-логики в нашем случае на C#.

Но, как оказалось, ASP.NET Core приложение не делает практически ничего, кроме передачи данных между пользователями микросервиса и Tarantool

Фраза показалась немного грустной.

Да, надо поправить формулировку. Речь идёт про конкретный микросервис авторизации и аунтетификации. Потребители микросервиса естественно на .NET.

А ещё такой вопрос, раз уж у вас .net core были ли попытки изначально всё это хостить на линукс системе? И любопытна нагрузка сейчас на этот сервис, хотя бы порядок.

Так как наш сервис, использующий Tarantool и .NET Core c Linux, ещё в процессе разработки, то нормальных данных по нагрузке нет.


Но я склонен верить результатам тестов ASP.NET
(конечно потом проверю всё сам для нашего сервиса):
https://github.com/aspnet/benchmarks


И Tarantool:
https://habrahabr.ru/company/mailru/blog/281841/

Даже базовый пример в коннекторе показывает, что вы неправы. Что вам кажется не работающим?

Всё отлично. Собственно выше указал на то, за что зацепился глаз и получил ответ.
А расскажете чем вам редис не угодил? Устанавливается next->next->next->finish, к нему есть нормальные клиенты, для .net есть stackexchange с прекрасной документацией, и ряд оберток поверх stackexchange на все случаи жизни если лень его самостоятельно готовить

На самом деле ответ на этот вопрос потянет на целую статью. На эту тему есть поста на 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.

Приходите на митап, я расскажу. Мы как раз с Редиса съезжаем.

Я знаю чем отличается редис от тарантула. Вопрос был к топикстартеру чем именно ИМ не угодил. Из текста статьи я ответа не нашел.

Там прямо в самом начале написано :) Если вы не согласны с тезисами авторами, это же не делает их неверными.

Ну я же не говорю что они неверны) Просто мы решали схожие проблемы, и выкрутились с редисом. Да из коробки меньше, но наличие отличных библиотек было определяющим фактором
Только зарегистрированные пользователи могут оставлять комментарии.
Войдите, пожалуйста.