]]>
6274https://cdn.slidesharecdn.com/ss_thumbnails/hrdbms1-170818152301-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0vinyl
/slideshow/vinyl-75591297/75591297
vinylpercona2017-170502075051 This is my talk on Vinyl storage engine internals at Percona Live Santa Clara 2017. Vinyl is a write opitmized storage engine based on log structured merge tree data structure that we delivered in Tarantool 1.7. ]]>
This is my talk on Vinyl storage engine internals at Percona Live Santa Clara 2017. Vinyl is a write opitmized storage engine based on log structured merge tree data structure that we delivered in Tarantool 1.7. ]]>
Tue, 02 May 2017 07:50:51 GMT/slideshow/vinyl-75591297/75591297KonstantinOsipov@slideshare.net(KonstantinOsipov)vinylKonstantinOsipovThis is my talk on Vinyl storage engine internals at Percona Live Santa Clara 2017. Vinyl is a write opitmized storage engine based on log structured merge tree data structure that we delivered in Tarantool 1.7. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/vinylpercona2017-170502075051-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> This is my talk on Vinyl storage engine internals at Percona Live Santa Clara 2017. Vinyl is a write opitmized storage engine based on log structured merge tree data structure that we delivered in Tarantool 1.7.
]]>
15155https://cdn.slidesharecdn.com/ss_thumbnails/vinylpercona2017-170502075051-thumbnail.jpg?width=120&height=120&fit=boundspresentationBlackhttp://activitystrea.ms/schema/1.0/posthttp://activitystrea.ms/schema/1.0/posted0My talk about Tarantool and Lua at Percona Live 2016
/slideshow/my-talk-about-tarantool-and-lua-at-percona-live-2016/61165990
percona2016-160420220451 In my talk I will focus on a practical use case: task queue
application, using Tarantool as an application server and a
database.
The idea of the task queue is that producers put tasks (objects)
into a queue, and consumers take tasks, perform them, mark as
completed.
The queue must guarantee certain properties: if a consumer failed,
a task should return to the queue automatically, a task can't be
taken by more than one consumer, priorities on tasks should be
satisfied.
With Tarantool, a task queue is a distributed networked
application: there are multiple consumer/producer endpoints
(hosts) through which a user can interact with the queue.
The queue itself is a fault-tolerant distributed database:
every task is stored in Tarantool database and replicated
in multiple copies.
If a machine goes down, the state of a task is tracked on a
replica, and the user can continue working with the
queue through a replica.
Total power failure is also not an issue, since tasks are stored
persistently on disk with transactional semantics.
Performance of such an application is in hundreds of thousands of
transactions per second.
At the same time, the queue is highly customizable, since it's
written entirely in Lua, is a Lua rock, but the code is running
inside the database. This is the strength of Lua:
one size doesn't have to fit all, and you don't have to sacrifice
performance if you need customization.
The second part of the talk will be about implementation details,
performance numbers, a performance comparison with other queue
products (beanstalkd, rabbitmq) in particular, and an overview
of the implementation from language bindings point of view: how we
make database API available in Lua, what are the challenges and
performance hurdles of such binding.]]>
In my talk I will focus on a practical use case: task queue
application, using Tarantool as an application server and a
database.
The idea of the task queue is that producers put tasks (objects)
into a queue, and consumers take tasks, perform them, mark as
completed.
The queue must guarantee certain properties: if a consumer failed,
a task should return to the queue automatically, a task can't be
taken by more than one consumer, priorities on tasks should be
satisfied.
With Tarantool, a task queue is a distributed networked
application: there are multiple consumer/producer endpoints
(hosts) through which a user can interact with the queue.
The queue itself is a fault-tolerant distributed database:
every task is stored in Tarantool database and replicated
in multiple copies.
If a machine goes down, the state of a task is tracked on a
replica, and the user can continue working with the
queue through a replica.
Total power failure is also not an issue, since tasks are stored
persistently on disk with transactional semantics.
Performance of such an application is in hundreds of thousands of
transactions per second.
At the same time, the queue is highly customizable, since it's
written entirely in Lua, is a Lua rock, but the code is running
inside the database. This is the strength of Lua:
one size doesn't have to fit all, and you don't have to sacrifice
performance if you need customization.
The second part of the talk will be about implementation details,
performance numbers, a performance comparison with other queue
products (beanstalkd, rabbitmq) in particular, and an overview
of the implementation from language bindings point of view: how we
make database API available in Lua, what are the challenges and
performance hurdles of such binding.]]>
Wed, 20 Apr 2016 22:04:51 GMT/slideshow/my-talk-about-tarantool-and-lua-at-percona-live-2016/61165990KonstantinOsipov@slideshare.net(KonstantinOsipov)My talk about Tarantool and Lua at Percona Live 2016KonstantinOsipovIn my talk I will focus on a practical use case: task queue
application, using Tarantool as an application server and a
database.
The idea of the task queue is that producers put tasks (objects)
into a queue, and consumers take tasks, perform them, mark as
completed.
The queue must guarantee certain properties: if a consumer failed,
a task should return to the queue automatically, a task can't be
taken by more than one consumer, priorities on tasks should be
satisfied.
With Tarantool, a task queue is a distributed networked
application: there are multiple consumer/producer endpoints
(hosts) through which a user can interact with the queue.
The queue itself is a fault-tolerant distributed database:
every task is stored in Tarantool database and replicated
in multiple copies.
If a machine goes down, the state of a task is tracked on a
replica, and the user can continue working with the
queue through a replica.
Total power failure is also not an issue, since tasks are stored
persistently on disk with transactional semantics.
Performance of such an application is in hundreds of thousands of
transactions per second.
At the same time, the queue is highly customizable, since it's
written entirely in Lua, is a Lua rock, but the code is running
inside the database. This is the strength of Lua:
one size doesn't have to fit all, and you don't have to sacrifice
performance if you need customization.
The second part of the talk will be about implementation details,
performance numbers, a performance comparison with other queue
products (beanstalkd, rabbitmq) in particular, and an overview
of the implementation from language bindings point of view: how we
make database API available in Lua, what are the challenges and
performance hurdles of such binding.<img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/percona2016-160420220451-thumbnail.jpg?width=120&height=120&fit=bounds" /><br> In my talk I will focus on a practical use case: task queue
application, using Tarantool as an application server and a
database.
The idea of the task queue is that producers put tasks (objects)
into a queue, and consumers take tasks, perform them, mark as
completed.
The queue must guarantee certain properties: if a consumer failed,
a task should return to the queue automatically, a task can't be
taken by more than one consumer, priorities on tasks should be
satisfied.
With Tarantool, a task queue is a distributed networked
application: there are multiple consumer/producer endpoints
(hosts) through which a user can interact with the queue.
The queue itself is a fault-tolerant distributed database:
every task is stored in Tarantool database and replicated
in multiple copies.
If a machine goes down, the state of a task is tracked on a
replica, and the user can continue working with the
queue through a replica.
Total power failure is also not an issue, since tasks are stored
persistently on disk with transactional semantics.
Performance of such an application is in hundreds of thousands of
transactions per second.
At the same time, the queue is highly customizable, since it's
written entirely in Lua, is a Lua rock, but the code is running
inside the database. This is the strength of Lua:
one size doesn't have to fit all, and you don't have to sacrifice
performance if you need customization.
The second part of the talk will be about implementation details,
performance numbers, a performance comparison with other queue
products (beanstalkd, rabbitmq) in particular, and an overview
of the implementation from language bindings point of view: how we
make database API available in Lua, what are the challenges and
performance hurdles of such binding.