Запросы к Twitter API на синтаксисе SQL

    Язык запросов TweeQL сделан по образцу SQL-синтаксиса и позволяет работать с базой твитов так же просто, как с реляционной базой данных.

    TweeQL имеет следующий синтаксис:

    SELECT field1, field2 FROM streams WHERE filter_conditions GROUP BY field3, field4 WINDOW x seconds

    Например, запрос вида

    SELECT text FROM twitter_sample WHERE text contains 'bobuk'; 

    просто вытягивает из потока твитов те фрагменты, в которых упоминается 'bobuk' (bobuk здесь просто ради примера как самый активный пользователь Twitter API в Рунете).

    Всё это без необходимости думать о всех деталях для правильного API-запроса.

    TWITTER_SAMPLE — это поток твитов, который содержит примерно 1% от общего их числа. Если нужно делать запросы к общему потоку, указывайте в качестве источника данных TWITTER.

    Отфильтрованные твиты можно сохранять в базу данных на локальном диске (её параметры задаются в settings.py). По причинам производительности запись в базу данных осуществляется только при достижении 1000 записей, так что если отфильтрованных записей меньше — они не сохранятся.

    TweeQL закодирован на Python.
    Поделиться публикацией

    Похожие публикации

    Комментарии 34
      +18
      Ализар?!
        +5
        Родители Анатолия — программисты. Отец и мать. Нет ничего удивительного в том, что сын разбирается в программировании.
          0
          Неужели, администрация хабра начала заказывать своим журналистам не только новостные, но и технические статьи…
          +2
          пропиарили бобука, будет теперь хвастаться SQL-запросом :)
            +2
            > TweeQL закодирован на Python.
            OMG! Он закодирован!
              +1
              А мы кашку ели, а мы гуляли, но мы не знали что такое обфусификация))
              –25
              Не хочу никого обижать, но SQL must die!
                +5
                Покормить вас что-ли, уж сильно проголодались, ну очень толсто.
                Где факты, сравнение, интриги, расследования?
                  +1
                  Вконтакте, Фейсбук и куча других крупных проектов работающих на *SQL не одобряют этот комментарий.
                    0
                    Вконтакте, Фейсбук и другие крупные проекты не используют фичи SQL типа join, group by и тяжелые запросы тоже.
                    Более того, во Вконтакте sql только как legacy штука стоит. У них собственная БД.
                    В фейсбуке все базы в формате key-value. Это sql назвать нельзя, я считаю.
                    0
                    Дмитрий, мне кажется вы слишком увлекаетесь альтернативными взглядами. SQL это язык запросов. Он может являться надстройкой не только над реляционными БД. Например Azure SQL =) такая мертвая тенденция, что прямо удивительно, что MS уделили ей место в keynote.
                    ИМХО сложно представить что-то более удобное и понятное для создания разноплановых запросов чем SQL.
                      0
                      Ну понятное дело что никто технологию в которую столько инвестировали убивать не хочет, но это не значит что она является «правильной» или «нужной».
                        0
                        ага, по вам лучше все дергать по индексам из массивов, зато быстро…
                    +1
                    Обидели
                      +1
                      Здорово, а в программы на питоне встроить можно?
                        +3
                        хотя, учитывая кто автор, наверно будет проще самому разобраться)
                          +1
                          from tweeql.exceptions import TweeQLException
                          from tweeql.query_runner import QueryRunner

                          runner = QueryRunner()
                          runner.run_query("SELECT text FROM twitter_sample;", False)
                          +4
                          Facebook это первым сделал, разработав FQL
                            +3
                            Фа Кью Эль?
                              +13
                              Пёрнуть ещё надо, и будет настоящий американский юмор.
                              Тогда можно будет смеяться.
                                –2
                                если пёрнуть, то это уже скорее канадский
                              0
                              Более того: FQL допускает множественные и вложенные запросы. Например,

                              "query1":"SELECT uid, rsvp_status FROM event_member WHERE eid=12345678"
                              "query2":"SELECT name, url, pic FROM profile WHERE id IN (SELECT uid FROM #query1)"


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

                              Интересно, как с этим у сабжа?
                              +2
                              а у .NET'чиков уже давно был LINQ to Twitter ^_^
                                0
                                Я не видел этот коммент, чесслово ;)
                                  0
                                  Видимо писать начали одновременно =)
                                +2
                                Также .NET-чикам может показаться интересным LINQ-провайдер под названием LINQ to Twitter.
                                  0
                                  Всё это без необходимости думать о всех деталях для правильного API-запроса.

                                  Ирония в том, что даже посредством родных запросов через API, сложные конструкции блокируются твиттером из-за их ресурсоёмкости. Чего уж там про SQL-подобные выборки говорить.
                                    0
                                    Ну сделали — молодцы, что тут скажешь. Единственное, что интересно — зачем?

                                    Тут, значит, наоборот пытаемся абстрагироваться от источников данных, используя REST, Data-сервисы, ORM, создаем LINQ-провайдеры ко всему и вся, пытаемся избавиться от magic-strings, используем NoSQL-хранилища там, где реляционные связи не дают должного профита, а тут внезапно появилась возможность использовать SQL там, где его изначально можно не использовать, да и быть не должно. Как по мне, это примерно как использовать SQL для доступа к свойствам объектов внутри ООП-языка.

                                    «позволяет работать с базой твитов так же просто, как с реляционной базой данных»
                                    В том то и дело, что с реляционной базой все «не так то просто». И тестировать сложнее.
                                      0
                                      Лично мне SQL хорошо понятен.
                                      В данном случае не нужно тратить время на изучение api твиттера, достаточно просто просмотреть названия баз\полей и сделать нужную выборку. Очень удобно.
                                      Я сам писал такую штуку для вконтактика, проект забросил, к сожалению.
                                        0
                                        «достаточно просто просмотреть названия баз\полей и сделать нужную выборку»
                                        Так вот вам и изучение API.

                                        Но «просмотрев поля» — так и придется сформировать API самому, для своего проекта.

                                        SQL — понятен, потому что стандартизирован. Но я придерживаюсь точки зрения, что SQL — не самая понятная вещь.
                                          0
                                          Да, к сожалению, не самая.
                                          Кстати, если каждый сайт будет использовать sql-like api на сайтах, то получим еще один хороший стандарт. Сейчас, вроде, каждый сайт городит что-то свое.
                                            0
                                            Стандарт есть — и это SOAP, и REST, не совсем стандарт, но на нем можно основать множество хороших соглашений. SOAP не сказать, что хорош, но SQL в любом случае не лучше. Но это, конечно, imho.
                                        0
                                        Как по мне, это примерно как использовать SQL для доступа к свойствам объектов внутри ООП-языка

                                        Судя по всему, вы не сталкивались с NSPredicate
                                          0
                                          Нет, не сталкивался, но сейчас посмотрел. К чему вы его отметили?

                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                      Самое читаемое