Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
stop
в одном джисоне.
Который тоже не очень-то "заточен на минимизацию трафика" :)
12 май 16, 17:08    [19165194]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
20 шт
Member

Откуда: Сообщений: 412780
Сообщений: 1186
miksoft
stop
в одном джисоне.
Который тоже не очень-то "заточен на минимизацию трафика" :)

В зазипованном джисоне! :)
12 май 16, 17:14    [19165235]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
20 шт
В зазипованном джисоне! :)
Это можно и к СУБД сжатие трафика прикрутить. Тот же OpenVPN умеет. А специализированные решения жмут еще лучше, хотя изрядно дорогие.
12 май 16, 17:21    [19165275]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 11092
miksoft,

Как сказал Дмитрий против высокой латентности канала это бесполезно.
12 май 16, 17:24    [19165290]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Симонов Денис
miksoft,

Как сказал Дмитрий против высокой латентности канала это бесполезно.
Это понятно, против нее все бесполезно, если передавать через канал интерактивные данные. В т.ч. и "джисон".
12 май 16, 17:29    [19165328]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
miksoft
Симонов Денис
miksoft,

Как сказал Дмитрий против высокой латентности канала это бесполезно.
Это понятно, против нее все бесполезно, если передавать через канал интерактивные данные. В т.ч. и "джисон".


Ну если вы будете на стороне базы данных из таблиц собирать джисоны, то может чтото и получится.

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

Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт.
Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб.
12 май 16, 18:54    [19165774]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 52968
stop, привет как сам?
12 май 16, 19:24    [19165897]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
mayton
stop, привет как сам?


Привет, норм.
Пилю по мере возмжностей крупный проект на Днипре, вычищаю баги.
У тебя как справы ?
12 май 16, 21:02    [19166333]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
asphix
Текущая поделка на Access 2007


Значит база < 2Gb. Посмотрите в сторону MS SQL Server 2014 Express Edition. И переход будет проще, и доп. нишнтяков поимеете (Reporting, FTS). Переносите по максимуму обработку данных на серверную сторону (хп). Клиент может остаться и на дельфе, хотя, его все равно придеться переписывать. Компоненты доступа к данным в принципе без разницы какие (если клиент будет дергать хп с сервера), лишь бы они вас устраивали по уровню совместимости с версией сервера в части поддерживаемых нововведений. Кстати, дельфа то какая?
12 май 16, 21:26    [19166436]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop
Про Джисон я сказал, потому что Иерархия явно лучше минимизирует и представляет данные для передачи по сети,
в отличии от типизированых таблицы с их датасетами.

Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт.
Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб.


Гм... Каким образом минимизирует? Зачем передавать всю иерархию по сети? Ну, вот классическое дерево. Пусть там на листьевом уровне будет 1 000 000 элементов. Показали пользователю первый уровень, состоящий, ну, скажем, из 10 узлов, показав признак наличия "детей" плюсиком, там где есть дети. Запросик будет простой, результат плоский, трафик минимальный. Будет пользователь кликать по плюсикам, будем подтягивать данные, выполняя все тот же самый серверный код.

Вы готовы заранее предугадать, какой плюсик кликнет пользователь, чтобы тащить нужный кусок иерархии? Или не доводилось работать с большим кол-вом детей? Это не сраказм и не наезд. Просто пытаюсь понять, как джисон мне сможет здесь помочь, заменив точеченые обращения к бд с получением результата в TDS.
12 май 16, 21:36    [19166515]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
miksoft
А специализированные решения жмут еще лучше, хотя изрядно дорогие.


Сложно говорить о дорогих специализированных решениях, когда заявленный автором канал - 128 КБит. Кстати, интересно, какой он в смысле физики...
12 май 16, 21:51    [19166650]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
stop
Про Джисон я сказал, потому что Иерархия явно лучше минимизирует и представляет данные для передачи по сети,
в отличии от типизированых таблицы с их датасетами.

Пакет с джисончиком для Днипры может состоять всего из нескольких байт и делать какойто мелкий апдейт.
Селект пользователя из базы, (симбиоз данных из примерно 20 таблиц еслиб они были в таблицах) занимает 2.3 кб.


Гм... Каким образом минимизирует? Зачем передавать всю иерархию по сети? Ну, вот классическое дерево. Пусть там на листьевом уровне будет 1 000 000 элементов. Показали пользователю первый уровень, состоящий, ну, скажем, из 10 узлов, показав признак наличия "детей" плюсиком, там где есть дети. Запросик будет простой, результат плоский, трафик минимальный. Будет пользователь кликать по плюсикам, будем подтягивать данные, выполняя все тот же самый серверный код.

Вы готовы заранее предугадать, какой плюсик кликнет пользователь, чтобы тащить нужный кусок иерархии? Или не доводилось работать с большим кол-вом детей? Это не сраказм и не наезд. Просто пытаюсь понять, как джисон мне сможет здесь помочь, заменив точеченые обращения к бд с получением результата в TDS.


Вы не совсем поняли суть того, о чем я говорил.
Если в джисоне (иерархии) можно представить обьект вот так,
и вернуть его за один запрос

{
type:'type',
members:[1,2,3,4,5,6,7,8,9.10]
}


То в реляционке все делается через джоин
membertype
1type
2type
3type
4type
5type
6type
7type
8type
9type
10type


Конечно, можно попытаться сделать два запроса (опять же трафик и латентность канала).
Может быть чтото попытается сжать сам провайдер RDBMS, но суть остается сутью.
12 май 16, 22:01    [19166700]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
Ну и разница в размере пакета, даже на таком простом примере уже в 2 раза.
Плюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах,
плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон.
12 май 16, 22:09    [19166718]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
pkarklin
Кстати, интересно, какой он в смысле физики...
С обоих (со всех, если их больше двух) концов канала стоит специальная железяка. Она умеет обучаться по проходящему трафику и накапливать статистику, по которой составляется частотный словарь для пакетов. При дальнейшей работе, когда нужно передать уже переданный ранее пакет (или данные прикладного протокола), передается только его номер по словарю. Железяки умеют работать как на уровне TCP/IP, так и на уровне ряда прикладных протоколов (в т.ч. SMB). Понимают ли они протоколы СУБД - не знаю. Естественно, пускать шифрованный VPN поверх такого канала неэффективно, ибо почти всегда будут промахи мимо словаря.
12 май 16, 22:11    [19166727]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop,

автор
То в реляционке все делается через джоин


Ах, вон Вы про что. Это сгодится, когда количество type ограничено десятками. В этом случае для лукапа выполнить один отдельный запрос. Если кол-во значений в type будет большим, как будет это выглядеть?
12 май 16, 22:12    [19166734]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
miksoft
pkarklin
Кстати, интересно, какой он в смысле физики...
С обоих (со всех, если их больше двух) концов канала стоит специальная железяка. Она умеет обучаться по проходящему трафику и накапливать статистику, по которой составляется частотный словарь для пакетов. При дальнейшей работе, когда нужно передать уже переданный ранее пакет (или данные прикладного протокола), передается только его номер по словарю. Железяки умеют работать как на уровне TCP/IP, так и на уровне ряда прикладных протоколов (в т.ч. SMB). Понимают ли они протоколы СУБД - не знаю. Естественно, пускать шифрованный VPN поверх такого канала неэффективно, ибо почти всегда будут промахи мимо словаря.


Прошу прощения, что я не правильно выразился и Вы меня неправильно поняли. Про физику я спрашивал в плане канала у ТС, а не о "специальных железяках".
12 май 16, 22:15    [19166737]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
stop
Если в джисоне (иерархии) можно представить обьект вот так,
и вернуть его за один запрос

{
type:'type',
members:[1,2,3,4,5,6,7,8,9.10]
}



То в реляционке все делается через джоин
membertype
1type
2type
3type
4type
5type
6type
7type
8type
9type
10type
В SQL тоже можно сериализовать (в т.ч. частично) результат и получить такую выборку:
memberstype
1,2,3,4,5,6,7,8,9,10type
12 май 16, 22:16    [19166743]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop
Ну и разница в размере пакета, даже на таком простом примере уже в 2 раза.


4K - это дефолтный размер пакета, который можно уменьшить до 512 для систем, неиспользующих bulk операции и обменивающимися малыми порциями данных. Ну, или увеличить до 16,383.

stop
Плюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах,
плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон.


Это легко можно проверить, в части размера трафика. Передача метаданных с данными - это одна из полезных фич, ибо понять без метаданных, что такое 20160512 невозможно.
12 май 16, 22:20    [19166760]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
stop,

автор
То в реляционке все делается через джоин


Ах, вон Вы про что. Это сгодится, когда количество type ограничено десятками. В этом случае для лукапа выполнить один отдельный запрос. Если кол-во значений в type будет большим, как будет это выглядеть?


А как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами
что ближе к реальности ?

Вот например, мой джисончик сущности User

private Widget CreateTestWidget()
        {
            return new Widget()
            {
                Author = new Author()
                {
                    IsPrivate = false,
                    Login = "Bob",
                    CreatedOn = DateTime.Now,
                    Likes = new List<Like>()
                                    {
                                        new Like()
                                        {
                                            Login = "Mary",
                                            OnDate = DateTime.Now
                                        }
                                    }

                },

                Name = "Widget",
                Description = "Widget Description",
                Picture = null,
                Comments = new List<Message>()
                                {
                                    new Message()
                                    {
                                        Author = new Author()
                                        {
                                            IsPrivate = false,
                                            Login = "Bob",
                                            CreatedOn = DateTime.Now,
                                            Likes = new List<Like>()
                                            {
                                                new Like()
                                                {
                                                    Login = "Mary",
                                                    OnDate = DateTime.Now
                                                }
                                            }
                                        },

                                        Text = null
                                    }
                                },

                Period = new Period()
                {
                    FromDate = DateTime.Now,
                    ToDate = DateTime.Now,

                    Type = "Month"
                },

                LasDocID = 10,

                Source = new Source()
                {
                    Type = "All",
                    Names = null
                },

                Conditions = new List<Condition>()
                                {
                                    new Condition()
                                    {
                                        OnlyTitle = false,
                                        Phrase = "phrase",
                                        Words = null,
                                        MinWords = 1,
                                        UseStemming = true
                                    }
                                },

                Output = new Output()
                {
                    Type = "Text"
                },

                Notifications = new List<Notification>()
                                {
                                    new Notification()
                                    {
                                        Type = "Email",
                                        Address = "bob@mail.com"
                                    }
                                },

                Price = new Price()
                {
                    Value = 10
                },

                LikedItems = new List<Item>()
                                {
                                    new Item()
                                    {
                                        Title = "Item title",
                                        URL = "Item URL",
                                        Text = "Item Text"
                                    }
                                }
            };
        }

        private User CreateTestUser()
        {
            User user = new User()
            {
                Author = new Author()
                {
                    IsPrivate = false,
                    Login = "Bob",
                    CreatedOn = DateTime.Now,
                    Likes = new List<Like>()
                    {
                        new Like()
                        {
                            Login = "Mary",
                            OnDate = DateTime.Now
                        }
                    }
                },

                Login = "Bob",
                Password = "test",
                From = "UA",
                Email = "bob@mail.ru",
                Picture = null,
                Age = 20,
                Interests = "Searching",

                Pages = new List<Page>()
                {
                    new Page()
                    {
                        Name = "Bob Page",
                        Description = "Bob Page Description",
                        Author = new Author()
                        {
                            IsPrivate = false,
                            Login = "Bob",
                            CreatedOn = DateTime.Now,
                            Likes = new List<Like>()
                            {
                                new Like()
                                {
                                    Login = "Mary",
                                    OnDate = DateTime.Now
                                }
                            }
                        },

                        Widgets = new List<Widget>()
                        {
                            CreateTestWidget(),
                            CreateTestWidget()
                        }
                    }
                },

                Favourits = new List<Item>()
                {
                    new Item()
                    {
                        Title = "Item title",
                        URL = "Item URL",
                        Text = "Item Text"
                    }
                },

                Libraries = new List<Library>()
                {
                    new Library()
                    {
                        Author = new Author()
                        {
                           IsPrivate = false,
                           Login = "Bob",
                           Likes = new List<Like>()
                           {
                                new Like()
                                {
                                    Login = "Mary",
                                    OnDate = DateTime.Now
                                }
                           },
                           CreatedOn = DateTime.Now
                        },

                        Category = "Library Category",
                        SubCategory = "Library SubCategory",

                        Name = "Name",
                        Descritpion = null,

                        Words = null,

                        ApproveWords = new List<ApproveWords>()
                        {
                            new ApproveWords()
                            {
                                Author = new Author()
                                {
                                    IsPrivate = false,
                                    Login = "Bob",
                                    CreatedOn = DateTime.Now
                                },

                                Words = null
                            }
                        }
                    }
                },

                BanList = new List<Author>()
                {
                    new Author()
                    {
                        IsPrivate = false,
                        Login = "Bob",
                        CreatedOn = DateTime.Now
                    }
                },

                Inbox = new List<Message>()
                {
                    new Message()
                    {
                        Author = new Author()
                        {
                            IsPrivate = false,
                            Login = "Bob",
                            CreatedOn = DateTime.Now,
                            Likes = new List<Like>()
                            {
                                new Like()
                                {
                                    Login = "Mary",
                                    OnDate = DateTime.Now
                                }
                            }
                        },

                        Text = null
                    }
                },

                Outbox = new List<Message>()
                {
                    new Message()
                    {
                        Author = new Author()
                        {
                            IsPrivate = false,
                            Login = "Bob",
                            CreatedOn = DateTime.Now,
                            Likes = new List<Like>()
                            {
                                new Like()
                                {
                                    Login = "Mary",
                                    OnDate = DateTime.Now
                                }
                            }
                        },

                        Text = null
                    }
                }
            };

            return user;

        }


Здесь гдето 2-3 кб данных если сериализовать.
Как это через таблицы вытянуть, какой трафик будет ?
Или опять на запросы дробить, что еще более смертельно для слабых каналов связи.
12 май 16, 22:21    [19166762]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Sayan Malakshinov
Member

Откуда: Мск
Сообщений: 5949
stop,

Сериализовывать в json сейчас все умеют...
12 май 16, 22:25    [19166771]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
miksoft
Member

Откуда:
Сообщений: 38919
stop
Плюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах,
плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон.
"Джисон" тоже не по голому TCP/IP обычно передается. Т.е. тоже HTTP-оверхэд присутствует.
12 май 16, 22:28    [19166781]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop,

автор
А как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами
что ближе к реальности ?


10-15 справочников в одном выносе? В части BI в плане звезды я еще могу представить такое. В транзакционной системе - нет.

автор
Вот например, мой джисончик сущности User


Много как-то букв. Если Вы по-русски опищите, что он делает, то я по возможности постараюсь оценить объем трафика. С Вас физическая модель данных только.
12 май 16, 22:29    [19166791]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
stop,

автор
А как будет выглядеть таблица, если джоинов будет не один, а допустим с 10-15 таблицами
что ближе к реальности ?


10-15 справочников в одном выносе? В части BI в плане звезды я еще могу представить такое. В транзакционной системе - нет.


Открытие даже какой нибудь самой простой учетной системы генерит обращение к десяткам таблиц уже при просто ее открытии.
В самой базе же могут быть сотни таблиц.

pkarklin
Много как-то букв. Если Вы по-русски опищите, что он делает, то я по возможности постараюсь оценить объем трафика. С Вас физическая модель данных только.


Там не на русском, там на С# готовая модель данных, которую можно запихнуть в какую нибудь ORM и оценить количество сгенерированых таблиц а также размер трафика, когда эту модельку нужно натянуть на вьюшку.
12 май 16, 22:38    [19166820]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop,

И я, к сожалению, не получил ответа на этот вопрос:

автор
Если кол-во значений в type будет большим, как будет это выглядеть?
12 май 16, 22:39    [19166822]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
miksoft
stop
Плюс MSSQL/Postgres еще чтото своего передаст о типах данных в столбцах и их размерах,
плюс еще служебных полей напихает, короче размер еще увеличится по сравнению с джисон.
"Джисон" тоже не по голому TCP/IP обычно передается. Т.е. тоже HTTP-оверхэд присутствует.


Смотря где.
В мой СУБД джисон пишется прямо в сокет, следовательно оверхед там считаные байты.
12 май 16, 22:40    [19166825]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить